Hi Luca, I'm one of the authors of Fiber and I will try to answer your questions.
Why use fasthttp over net/http?
The worker pool model is a zero allocation model, as the workers are already initialized and are ready to serve, whereas in the net/http implementation the go c.serve() has to allocate memory for the goroutine.
The handler function definition signature is better, as it takes in only a context which includes both the request and writer needed by the handler.
Overall fasthttp is a zero allocation model with a low memory footprint.
Lack of HTTP/2 support
Proxies/load-balancers like nginx, cloudflare ...etc take care of the HTTP/2 requests from the client browser. Most proxies do not support the HTTP/2 protocol from and to origin servers, since most web apps are behind a proxy/load-balancer this should not be a problem.
"hackish", implementation of WebSockets
I'm not sure what you mean with "hackish" but Fiber uses github.com/gorilla/websocket and this is a fast, well-tested and widely used WebSocket implementation for Go.
Where and when should I use Fiber over something like Echo?
If you need raw performance with a low memory footprint.
If you ever worked with Expressjs (Fiber has a similair API).
In the end it's up to you where you feel more comfortable
I hope I answered your questions, and if you have more feel free to ask!
Hadn't thought about how proxies and load-balancers can help with the lack of HTTP/2 support.
The worker pool model is great, wonder why it couldn't be adopted by the standard lib, probably some lower level problem I'm not currently aware of.
As for Fiber, are you guys tackling documentation right now? I found the lack of a godoc page to slow my efforts in messing with the framework. Does the team need any help in this aspect?
Anyhow, thanks for the response and I wish the team good luck!
We have an extended online API documentation: fiber.wiki
I forgot to add some benchmark sources that might change your mind to use fiber versus other frameworks:
Is it advantageous to use a framework built on top of a custom HTTP stack (fasthttp) over other frameworks based on net/http for production?
The lack of HTTP/2 support and the, seemingly "hackish", implementation of WebSockets seem to outweigh the benefits to speed (read req/s).
Where and when should I use Fiber over something like Echo?
P.S.: The work on Fiber is great, hope to see it flourish in the future!
Hi Luca, I'm one of the authors of Fiber and I will try to answer your questions.
Why use fasthttp over net/http?
The worker pool model is a zero allocation model, as the workers are already initialized and are ready to serve, whereas in the net/http implementation the go c.serve() has to allocate memory for the goroutine.
The handler function definition signature is better, as it takes in only a context which includes both the request and writer needed by the handler.
Overall fasthttp is a zero allocation model with a low memory footprint.
Lack of HTTP/2 support
Proxies/load-balancers like nginx, cloudflare ...etc take care of the HTTP/2 requests from the client browser. Most proxies do not support the HTTP/2 protocol from and to origin servers, since most web apps are behind a proxy/load-balancer this should not be a problem.
"hackish", implementation of WebSockets
I'm not sure what you mean with "hackish" but Fiber uses github.com/gorilla/websocket and this is a fast, well-tested and widely used WebSocket implementation for Go.
Where and when should I use Fiber over something like Echo?
If you need raw performance with a low memory footprint.
If you ever worked with Expressjs (Fiber has a similair API).
In the end it's up to you where you feel more comfortable
I hope I answered your questions, and if you have more feel free to ask!
Thanks for the awesome reply Fenny.
Hadn't thought about how proxies and load-balancers can help with the lack of HTTP/2 support.
The worker pool model is great, wonder why it couldn't be adopted by the standard lib, probably some lower level problem I'm not currently aware of.
As for Fiber, are you guys tackling documentation right now? I found the lack of a godoc page to slow my efforts in messing with the framework. Does the team need any help in this aspect?
Anyhow, thanks for the response and I wish the team good luck!
No problem!
We have an extended online API documentation: fiber.wiki
I forgot to add some benchmark sources that might change your mind to use fiber versus other frameworks:
Plaintext
techempower.com/benchmarks/#sectio...
JSON serialization
techempower.com/benchmarks/#sectio...
Data updates
techempower.com/benchmarks/#sectio...