Middleware and DI: the two patterns that shape every backend

Two orthogonal axes

Before you can fix a backend architecture problem, you need to know which axis it lives on — otherwise you reach for the wrong tool entirely. Middleware and dependency injection answer different questions, and confusing them is a common source of muddled architecture:

• Middleware is about the request axis — what runs around a handler on every request, in what order. It is dynamic, per-request, and ordered: auth, logging, body parsing, rate limiting. The previous unit showed why that order is a security boundary.
• Dependency injection is about the wiring axis — what objects a piece of code is given instead of constructing itself. It is mostly static, decided at startup, and about coupling and testability: a handler receives a UserRepository rather than calling new UserRepository() inside itself.

One is a pipeline; the other is a graph. A request travels the pipeline; the graph is assembled once before any request arrives.

Why middleware exists: cross-cutting concerns

Auth, logging, tracing, compression, and error handling are needed by almost every endpoint but belong to none of them. Without middleware, each handler re-implements them — inconsistently. Middleware factors these cross-cutting concerns into ordered layers that wrap the handler, so they are written once and applied uniformly.

Why DI exists: inversion of control

When a class calls new EmailService() internally, it is welded to that exact implementation: you cannot swap it for a fake in a test, point it at a different config, or reuse the class elsewhere. Inversion of control flips this — the class declares what it needs (an emailer) and something external decides which concrete one it gets. That external place is the composition root, the single spot near startup that knows the real implementations and wires the object graph.

They meet in the framework

Real frameworks fuse the two. NestJS controllers are resolved from a DI container and sit behind a middleware/guard/interceptor pipeline. Express keeps DI implicit (you wire by hand or req-attach), but the middleware model is explicit. Recognizing which axis a problem lives on is the senior reflex: “this endpoint is slow on every request” is usually middleware; “this class is impossible to test” is usually DI.

The two axes also have very different cost profiles, which is why they are worth separating. Middleware cost is per request and recurring: each layer in an Express chain typically adds single-digit microseconds of overhead, but a bloated 12–15-layer chain (auth, logging, body parse, compression, CORS, helmet, rate limit, etc.) can add roughly 0.3–0.5ms at p50 and 1–3ms at p99 once GC and a slow async layer like an audit log are in play — multiplied by every request, that is real throughput. DI cost is mostly paid once at startup: a NestJS app with a few hundred providers spends on the order of tens to low-hundreds of milliseconds building its graph at boot, then serves requests with singletons at near-zero per-request wiring cost. So a middleware mistake taxes every request forever; a DI mistake usually taxes only the boot (with one sharp exception — request-scoped providers, covered in lesson 04, that drag wiring cost back into the per-request hot path).