Python Middleware Patterns — Core Concepts

What Is Middleware?

Middleware sits between the incoming request and your application logic. It can inspect, modify, or short-circuit both requests and responses. Think of it as a pipeline: each middleware is a stage that the request flows through before reaching your endpoint, and the response flows back through on the way out.

Every major Python web framework — Django, Flask, FastAPI, Starlette — supports middleware, though the API differs.

How the Pipeline Works

The request lifecycle with middleware looks like this:

1. Client sends request → hits the first middleware
2. Each middleware can modify the request, reject it, or pass it along
3. Your view/endpoint processes the request and returns a response
4. Each middleware (in reverse order) can modify the response
5. Client receives response

This “onion model” means outer middleware wraps inner middleware. The first middleware added is the first to see the request and the last to see the response.

Common Middleware Use Cases

Authentication and authorization — Check tokens or session cookies before any endpoint runs. If invalid, return 401 immediately without ever reaching your view.

Request logging — Record the method, path, and timing of every request. This is cross-cutting: you want it everywhere, but you don’t want to add logging to each endpoint individually.

CORS handling — Add the right headers so browsers allow cross-origin requests. This must happen consistently on every response, making it a perfect middleware job.

Rate limiting — Track request counts per client and reject excess traffic early in the pipeline.

Error handling — Catch unhandled exceptions and convert them to clean error responses instead of leaking stack traces.

The Pattern Across Frameworks

In Django, middleware is a class with methods like process_request and process_response, or the newer __call__-based style where you wrap the get_response callable.

In FastAPI/Starlette, you write an async function or class that receives the request and a call_next function. You call call_next(request) to pass through to the next layer.

In Flask, you can use before_request and after_request decorators, or write WSGI middleware that wraps the app directly.

Despite the syntax differences, the core idea is identical: wrap the handler, do work before and/or after.

Ordering Matters

Middleware order is one of the most common sources of bugs. If your authentication middleware runs after your logging middleware, you’ll log unauthenticated requests as if they were valid. If CORS middleware runs too late, preflight requests fail silently.

Rule of thumb: security middleware should run early (close to the outside), logging middleware should wrap everything, and transformation middleware (compression, serialization) should run close to the response.

Common Misconception

“Middleware is just for HTTP.” While the pattern is most visible in web frameworks, middleware appears everywhere — message queues, CLI tools, and testing frameworks all use the same wrap-and-delegate concept. The Python ecosystem calls these “hooks,” “plugins,” or “interceptors,” but the underlying pattern is the same pipeline.

The one thing to remember: Middleware separates cross-cutting concerns from business logic — each layer does one job, and the order you stack them determines how requests flow through your application.