16 posts tagged with "v3"

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.

There is a moment in every project's life where someone greps the production logs for a bug report and realizes that fmt.Println("got here") is the only evidence of what happened. The request came in, something went wrong, and the logs show a status code with no context about which user, which endpoint, or which upstream service was involved.

Logging sounds boring until it is 2 AM and your only debugging tool is kubectl logs. At that point, the difference between a flat text line and a structured JSON object with a request ID, latency, and user context is the difference between finding the bug in five minutes and finding it in two hours.

Fiber v3's Logger middleware is designed to bridge that gap without requiring you to rewrite your application.

Every Fiber tutorial shows you how to test a single GET handler. Create an app, register a route, call app.Test(), check the status code. Done.

Then you try to test something real — a middleware chain where auth runs before validation, a custom error handler that renders different responses based on content type, a route group with shared state — and the tutorial patterns fall apart. The handler works in isolation but fails when composed. The test passes with a hardcoded body but breaks when you add a request ID middleware that changes the response shape.

Testing Fiber applications well requires patterns that match how Fiber applications actually work: as compositions of handlers, middleware, and configuration that interact in specific ways.