Middleware — Logging, CORS, Timing

Understanding the Middleware Lifecycle

Middleware is essentially a function that sits between the client and your path operations, intercepting the request-response lifecycle. When a request hits your server, the middleware intercepts it first, allowing you to manipulate headers, log details, or even terminate the request early. After the middleware performs its initial task, it calls the 'next' handler to pass control deeper into your application. Crucially, the response then flows back out through this same middleware, giving you a second opportunity to modify headers or perform post-processing tasks before the response is finally returned to the client. This 'wrapping' behavior is why middleware is so powerful; it provides a single, centralized location to implement cross-cutting concerns that would otherwise need to be redundantly duplicated inside every single individual endpoint function in your entire codebase.

from fastapi import FastAPI, Request
import time

app = FastAPI()

@app.middleware("http")
async def simple_middleware(request: Request, call_next):
    # This part runs before the request is processed
    print(f"Processing request: {request.url.path}")
    
    # call_next passes the request to the next middleware or route
    response = await call_next(request)
    
    # This part runs after the response is generated
    print("Finished processing request")
    return response

Implementing Request Timing

Timing middleware is a classic use case for monitoring application performance. By capturing a high-resolution timestamp immediately upon entering the middleware and subtracting it from a second timestamp taken after the response is generated, you can accurately measure the total latency of each request. This is critical for identifying bottlenecks, such as slow database queries or inefficient business logic, without needing to manually add timing logic to every endpoint. Because the middleware waits for the 'await call_next(request)' to finish, the returned time represents the complete round-trip duration through your router, validation, and endpoint processing. This observability allows developers to implement automated performance alerting or include timing metadata in custom response headers, which is invaluable for debugging production issues where latency spikes might be intermittent or specific to certain payload sizes or request types.

import time

@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
    start_time = time.perf_counter()
    response = await call_next(request)
    process_time = time.perf_counter() - start_time
    
    # Add a custom header with the time taken to process the request
    response.headers["X-Process-Time"] = str(process_time)
    return response

Logging Requests and Responses

Logging middleware provides an audit trail of how your application interacts with the outside world. Instead of simply relying on access logs provided by the web server, custom middleware allows you to extract specific details—such as User-Agent strings, specific header values, or even internal error codes—that are relevant to your business context. By wrapping the call_next execution in a try-except block, you can ensure that even when an endpoint crashes with an unhandled exception, your middleware can log the failure before passing the error up. This level of granular insight ensures that you can trace requests through your system, which is vital in a distributed environment or a complex monolithic application where identifying the source of a problematic request is otherwise like looking for a needle in a haystack. Properly structured logs allow for later analysis of usage patterns, security audits, and debugging.

import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("http_logger")

@app.middleware("http")
async def log_requests(request: Request, call_next):
    logger.info(f"Endpoint hit: {request.method} {request.url.path}")
    try:
        response = await call_next(request)
        return response
    except Exception as e:
        logger.error(f"Unhandled error: {e}")
        raise e

Managing Cross-Origin Resource Sharing (CORS)

CORS middleware is a mandatory security configuration when your application serves as an API for web-based frontends hosted on different domains. Browsers enforce the Same-Origin Policy, which prevents scripts on one domain from accessing data from another unless explicitly permitted by the server. Using the built-in CORSMiddleware is the standard way to inform browsers which origins, methods, and headers are acceptable. By setting 'allow_origins', you define a whitelist of trusted sources. Without this middleware, your API would fail to respond to cross-origin AJAX requests, effectively rendering it useless for standard web applications. It is important to realize that this middleware doesn't just block requests; it dynamically handles 'preflight' OPTIONS requests sent by the browser. By offloading these complex security negotiations to the middleware layer, you keep your route handlers focused solely on business logic, ensuring that your security posture is consistent and easily auditable across all exposed routes.

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:3000"], # List of allowed domains
    allow_credentials=True,
    allow_methods=["GET", "POST"], # Allowed HTTP verbs
    allow_headers=["*"], # Allow all headers
)

Best Practices for Middleware Complexity

While middleware is powerful, it is also a global singleton; poorly written middleware can introduce latency or bugs into every request. Keep your middleware logic as lean as possible; avoid performing expensive I/O operations or database lookups directly inside the middleware unless absolutely necessary, as this will force every single user request to bear that performance penalty. Always ensure that exceptions inside your middleware are handled gracefully so that you do not accidentally swallow errors that should be returned to the client as proper HTTP 500 responses. Furthermore, order matters significantly in FastAPI because middleware is executed in a 'last-added, first-executed' stack. If you have both logging and CORS middleware, the one added last will see the request first. By carefully sequencing your stack, you ensure that security checks occur before logging, providing a robust architecture that handles traffic predictably from the very first byte.

# Middleware stack order is important
# The last middleware added is the first one executed
app.add_middleware(CORSMiddleware, allow_origins=["*"])
# This logger will be called AFTER the CORS middleware
@app.middleware("http")
async def global_logger(request, call_next):
    print("Logging request inside global scope")
    return await call_next(request)

Interview questions

All FastAPI interview questions →

Check yourself

Take the full FastAPI quiz →