Middleware and DI: the two patterns that shape every backend

Two engineers describe the same backend. One says “every request flows through auth, logging, and validation before the handler.” The other says “the handler gets a database client, a cache, and a mailer it never created.” They are describing the same code from two angles: the request flowing through layers, and the dependencies flowing into objects. Those two angles are middleware and dependency injection — and almost every framework decision you will make is one or the other.

Two orthogonal axes

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.