For a lot of applications - admin panels, dashboards, internal tools, CRUD frontends - the default stack of a JavaScript SPA talking to a JSON API is more machinery than the problem needs. Two codebases, a bundler, a node toolchain in CI, and client-side state that mirrors what the server already knows.

HTMX takes the opposite approach: the server renders HTML, and a small script extends HTML with attributes like hx-get and hx-target so any element can fetch a fragment and swap it into the page. No build step, no client-side router, no JSON serialization layer.

Fiber is a natural fit for this. Its template engines render fragments fast, the whole application compiles to one binary, and the request handling you already know - routing, binding, middleware - is all there is to learn. Let's build a live-search contact list to see the full loop.

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.

Almost every REST API has a handler that starts like this:

app.Get("/users/:id", func(c fiber.Ctx) error {
    id, err := strconv.Atoi(c.Params("id"))
    if err != nil {
        return fiber.ErrBadRequest
    }
    // ... finally, the actual logic
})

Three lines of ceremony before the handler does anything useful, repeated in every handler that takes a numeric parameter. Fiber has a feature that moves this check into the router itself: route constraints. Declare the parameter as :id<int> and the route simply does not match for /users/abc. Your handler only ever sees values that passed the check.

Constraints arrived back in v2.37 and were inspired by .NET Core routing. They remain one of the least-known routing features, which is a shame, because they remove boilerplate exactly where it accumulates fastest.