GoLang Web frameworks

Chi isn’t really a framework, it’s more of a library that gives syntactic sugar over the standard library and some middleware functions. A lot of what Chi offers can be done in the standard library now.

If you are coming from other languages where frameworks are the go to, you’ll probably find a familiar feeling using something like Gin or Echo. A lot of Go developers prefer the simplicity and power of using the standard library or a wrapper like Chi.

It is a library that lets you define “routes” for requests in the form of paths and http methods. The library then routes your http request to the associated handler function. Many routers provide some form of middleware functionality to add operation either before or after the request has been handled. This is smaller than a “framework”.

Since 1.22+, Standard library all day. It really doesn’t matter, but I typically don’t use libraries unless there’s a significant benefit or it’s a random side project and I don’t need to be able to understand everything that’s happening under the hood.

Fiber: doesn’t use the core http library for a theoretical performance gain. I find the fact that they decided to use a different library makes it less portable and not worth it.
Chi: Very nice over all. It’s minimalistic and provides what you needED to get you going. Most of its feature are basically in Go core’s recent versions.
Gin: haven’t used it enough to comment, it’s an option.
Echo: It was the first framework I used. I think it gives you everything you need out of the box. You have plenty of middleware and cookbook recipes to let you do pretty much whatever you need.

So, if I was new and getting started and wanted to something to ‘just work’, I’d use echo, if I had the opportunity to start fresh on current project? I’d probably look at core lib/ chi.

Chi is still relevant, the stdlib got better but still not there and that weird syntax they added for routes…

Scalability -

The scalability of your application is determined by how well you structure your project layout and code. While none of these frameworks inherently facilitate scalability, they can complicate it, especially when integrating certain libraries and services that may not be compatible with the framework code. This issue will arise at the most inconvenient time.

Performance -

The performance differences between frameworks are so minimal that they are hardly worth discussing. Although Fiber uses fasthttp, which is faster than net/http, this advantage becomes negligible in real-world scenarios involving a database connection and calls.

Golang and Frameworks -

Coming from other languages to Golang can be a curse and a blessing. Unlike PHP and Python, which require frameworks or numerous libraries to achieve what Golang’s standard library offers out of the box, Golang frameworks are generally lightweight and perform well. Programmers focused on framework performance in PHP and Python are often seeking the least slow option. In contrast, most Golang frameworks are advanced routers with additional functionality, prewritten middleware (often of poor quality), and redundant rewrites of standard library functions with little added value. Beyond routing and middleware, most applications using these frameworks do not leverage much else.

Recommendations -

Use the standard library and add separate middleware and libraries as needed.

Consider CHI or Gorilla to benefit from enhanced router syntax and prewritten middleware.

Opt for Echo, Gin, or Fiber (in that order) if a framework is necessary.

While I am generally pro-framework, some can introduce more challenges than they resolve. In go world framework developers spend their time solving problems that have already been solved by making something simple a little more simpler…..and unnecessary.

If you have to ask, then the answer is that all of them have basically the same scalability/performance for your usecase. They are all reasonably close to each other.

Go standard library whenever possible (or Chi) is the best option if you are new to Go or if you want to be able to come back to the project after 5+ years without maintenance, simply because it minimizes the number of dependencies, and lets you use stdlib compatible middlewares straightforwardly which are most of the Go ecosystem.

There’s no reason to use a framework in go. Go has the best http server of any programming language I’ve ever worked in.

Standard only. I am using RPC implemetation over http for almost 5y now. Very, veeery little use of middleware, mostly throttle, auth and acl. It’s fast, simple, predictible and my personal favourite, generatable.

I can easely convert an interface into an http handler.

type Service interface { SomeAction(SomeActionReq) SomeActionRes }

Translates to a route such: [POST] rpc/Service/SomeAction

If at some point REST Api is needed I can take service and implement needed actions into REST like urls, but this is mostly for 3rd party users.

Links to this note

GoLang notes