2 posts tagged with "patterns"

You use logger, cors, and limiter every day. Sooner or later you need something Fiber does not ship: tenant resolution from the hostname, an audit trail, a company-specific auth header. The instinct is to look for a plugin API or an interface to implement.

There is none, and that is the point. A Fiber middleware is an ordinary handler - func(c fiber.Ctx) error - that calls c.Next() to hand control to the rest of the chain. Everything else, including the polished config pattern the official middleware uses, is convention on top of that one idea.

This post walks through the whole ladder: the minimal middleware, short-circuiting, passing data downstream, and the official Config convention, ending with the one caveat that catches almost everyone.

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.