Routing and middleware: choosing what runs, and in what order

A security review finds that one admin endpoint accepts unauthenticated requests. The auth middleware exists, it is well-tested, and it is applied — but it was registered after the route in question. The handler ran first. Nobody wrote a bug; someone wrote the lines in the wrong order.

Routing: matching a path to a handler

Routing turns POST /users/42/orders into a single handler plus extracted params (userId=42). How it matches determines its cost:

• Linear scan — try each registered route in order. Simple, but O(n) in route count; fine for dozens of routes.
• Radix trie (httprouter, Echo, Fastify’s find-my-way) — a prefix tree over path segments. O(length of path), independent of route count, so 10 routes and 10,000 routes match in the same time.

In practice routing is microseconds either way; it almost never dominates latency. The real routing bugs are correctness: overlapping patterns (/users/:id vs /users/me), trailing-slash mismatches, and method confusion (a GET route shadowing a POST on the same path).

Middleware: the chain around the handler

Middleware are functions that run before and/or after the handler, each able to read the request, modify it, short-circuit it, or pass control onward. They handle cross-cutting concerns — things every endpoint needs but no endpoint should re-implement: authentication, request logging, body parsing, rate limiting, compression, error handling.

The model is an onion. A request travels inward through each layer to the handler, then the response travels outward through the same layers in reverse:

request →  logging → auth → bodyParser → handler
response ← logging ← auth ← bodyParser ← handler

A layer that calls next() passes control inward. A layer that responds without calling next() short-circuits — the handler never runs. That is exactly how a rate limiter returns 429 or an auth layer returns 401 before any business logic executes.

Order is a security boundary

Because each layer can short-circuit, the order of registration decides what actually protects the handler:

The rule that prevents all five: cheap and protective layers go first (size limits, rate limits, auth), expensive and optional layers go last (body parsing, compression), and the error handler goes outermost so it wraps everything.

Where time actually goes

Middleware is also where invisible latency accumulates. Each layer runs on every request. A body parser that JSON-parses a 1 MB payload, a logging layer that does a synchronous DNS lookup, an auth layer that calls a remote token service without caching — these add milliseconds to every request, not just the slow ones. Profiling a slow endpoint means timing the chain, not just the handler.