People in the Go community often respond with "use net/http for building web apps", the standard library is good enough and has better support in the long run. This is good advice in most cases. However, if you are using Go for API building and explicitly want to squeeze out every little bit of performance, then there are much faster libraries available than the standard net/http. Gnet is one such example.
And what are the downsides? Hard to maintain code? Having to deeply integrate the code to get the advertised performance?<p>Also: "Multiple Porotocols"<p>Oh, there it is on the github: "Note that the HTTP implementation of gnet on TechEmpower is half-baked and fine-tuned for benchmark purposes only and far from production-ready."
<a href="https://gnet.host/docs/about/overview/" rel="nofollow">https://gnet.host/docs/about/overview/</a> - This is a very similar threading model to envoy [0] and lmax disruptor [1]. Unfortunately IIUC writing this in Go still prevents the spin-locked acceptor thread from achieving the kind of performance you could get in a non-GC language, unless you chose to disable GC, so I'd guess Envoy is still faster.<p><a href="https://gnet.host/docs/quickstart/" rel="nofollow">https://gnet.host/docs/quickstart/</a> it's nice that you can use this simply though. Envoy is kind of tricky to setup with custom filters, so most of the time it's just a standalone binary.<p>[0] <a href="https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310" rel="nofollow">https://blog.envoyproxy.io/envoy-threading-model-a8d44b92231...</a><p>[1] <a href="https://lmax-exchange.github.io/disruptor/#_what_is_the_disruptor" rel="nofollow">https://lmax-exchange.github.io/disruptor/#_what_is_the_disr...</a>