Sandro Turriate

3 reasons to use Fiber over Gin for your next Go web project

I recently switched from using Gin to Fiber for building my site generator. Fiber was the third web framework I moved to, starting first with Iris, then moving to Gin, before finally using Fiber.

After moving from Iris to tried and true Gin, switching frameworks again was the last thing I wanted to do, but when my routes became sufficiently complex, I had no choice.

Iris

But first, why wasn’t I happy with Iris? The tool looks great, and so do the docs—at first glance, but in the end, I experienced a dizzying array of documentation in different location for different versions (v12 was the latest at the time, not merged to master) which didn’t always work as shown. I generally have a high tolerance for out of date documentation because I understand how difficult it is to keep the docs in sync with the code, so I tend to just read the source instead, but the source what finally made me switch.

The Iris source code is not easy to read, at least on Github. The project is broken down into many files over many packages, and I often found myself reading the wrong version of a file because I was viewing the master branch. Compared to Gin which I knew, and Fiber, where the bulk of the code is in a single Go file, Iris simply wasn’t worth the effort of digging through documentation for my simple project. Maybe my experience would have been different if I bought the book, but I'm not ready for that type of open source gatekeeping

Gin

Gin is a great piece of software. It's been around forever and uses the standard Handler interface from net/http which makes it comfortable to use and easy to add to any project. The code is clean, easy to navigate, and easy to understand. Switching from Iris to Gin was actually fairly simple because they both offer a lot of the same primitives, and both use the same type of handler functions. It wasn't until my routing began to resemble a standard REST API that I ran into issues with the router. I searched the issue list on Github and found a handful of people reporting the same problem I faced. Maybe a few handfuls. One issue sums it up succinctly…

To everyone who's new here:

If you use RESTful-Style API, router of gin will be a TROUBLEMAKER!

• 205
• 1681
• 136
• 2005

The root of the problem is httprouter

I read multiple comments like the one above, akin to “implementing REST? You need a different router.” I wanted RESTful routes but I also needed nontrivial wildcard routes. I thought about using go:generate to create the dynamic routes I knew I needed beforehand, but after hacking a few makeshift, I decided to look for another framework.

Fiber

I found a link to Fiber and decided to give it a try. I was skeptical at first because it’s influenced by a piece of node software, and I’m generally leery of all things node, but I decided to try it. I immediately tested my routing issue, and was happy when Fiber handled the problem in a perfectly sane way.

3) Responsive dev team

I did have one problem however. My wildcard route was returning inconsistent results! Just when everything was looking so promising. I submitted a bug report which was acknowledged within 4 hours, and had a PR the next day!

I began porting my code from Gin to Fiber and was thrilled to find that Fiber had a parallel for everything I did in Gin. At times, I found myself deep in the fasthttp codebase, which Fiber effectively wraps, and that took some getting used to, but when I’m there I’m happy to be there because I know I’m that much closer to the metal.

Fiber’s source is very predictible to read. Most everything you care about is in ctx.go or app.go, and it ships with some very useful middleware like favicon, etag, pprof, filesystem, and more. So far, Fiber is my favorite Go web server, and I hope it works for you too!