4 posts tagged with "migration"

Fiber's API was inspired by Express, and it shows: routes look the same, parameters use the same :name syntax, middleware chains work the way you expect. If you know Express, you already know most of Fiber - you just do not know the spelling yet.

This post is the phrasebook. Express on the left, Fiber v3 on the right, organized by what you do all day: read requests, write responses, chain middleware, handle errors. At the end, the three differences that are not spelling - the ones that cause real bugs when Node instincts meet Go.

If you have ever tried to migrate a project from Express.js to Go, you know the friction. It is not the language syntax or the type system. It is that every HTTP handler follows a completely different convention. Express gives you (req, res, next). Go's standard library gives you (w, r). Fiber gives you (c) error. The logic is the same, but the shape is different, and reshaping hundreds of handlers is tedious, error-prone work.

Fiber v3 decided to stop pretending this is not a problem. Its handler adapter accepts seventeen different function signatures - from Fiber-native to Express-style callbacks to raw net/http and fasthttp handlers. You can mix them in the same application without manual wrapping.

This sounds like magic. It is actually a carefully designed type switch in adapter.go that performs this adaptation at runtime when routes are registered, instead of forcing you to do it by hand.

One of the most underrated improvements in the v3 router is not a new method or fancy syntax. It is handler compatibility.

In plain terms: Fiber can now accept multiple handler styles directly, and the router compatibility layer adapts them for you. That sounds small until you are migrating a real codebase with hundreds of handlers, middleware functions, and utility packages in different styles. Then it becomes the feature that decides whether migration happens this quarter or gets postponed again.