2 posts tagged with "architecture"

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.

As backend services mature, handlers start repeating the same request plumbing over and over again. Tenant resolution, actor identification, correlation values, access-scoped metadata. None of this is business logic, but all of it is required before any business logic can run.

In a typical multi-tenant API, every handler opens with five or six lines of header extraction and default-value logic. When that logic is duplicated across fifty endpoints, small inconsistencies creep in. One handler reads X-Tenant-ID, another reads X-TenantID, a third falls back to a query parameter. Custom context gives that plumbing a single, typed home.