3 posts tagged with "migration"

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.

When most teams read a "what's new" post, they are usually looking for one of two things.

The first is curiosity: what did the framework ship? The second is risk management: what do we need to change first, and what can wait until later?

For Fiber v3, the second question is the important one.

The release includes a lot of meaningful work, but a few parts have outsized impact in real services: request binding, lifecycle hooks, listen configuration, handler compatibility, context improvements, and the new extractors package.

This article is intentionally written for that reality. You should be able to read this, open one service in your codebase, and know exactly what to migrate first and why.