Why middleware processes requests before handlers in NestJS - Why It Works This Way

Overview - Why middleware processes requests before handlers

What is it?

Middleware in NestJS is a function that runs before the main request handler. It can inspect, modify, or stop requests before they reach the handler that sends a response. This helps organize code by separating common tasks like logging, authentication, or data parsing from the main logic.

Why it matters

Without middleware running first, every handler would need to repeat common tasks, making code messy and error-prone. Middleware ensures these tasks happen consistently and early, improving security, performance, and maintainability. It’s like a checkpoint that prepares requests before they reach their destination.

Where it fits

Before learning middleware, you should understand basic request handling and routing in NestJS. After mastering middleware, you can explore advanced topics like guards, interceptors, and exception filters that also influence request processing but at different stages.

Mental Model

Core Idea

Middleware acts as a gatekeeper that processes requests first to prepare or filter them before the main handler responds.

Think of it like...

Middleware is like the security checkpoint at an airport that checks passengers before they board the plane. It ensures only safe and ready passengers proceed to the flight, just like middleware ensures requests are ready and safe before handlers process them.

┌───────────────┐
│ Incoming      │
│ HTTP Request  │
└──────┬────────┘
       │
┌──────▼────────┐
│ Middleware    │  <-- Processes request first (e.g., logging, auth)
└──────┬────────┘
       │
┌──────▼────────┐
│ Request       │
│ Handler       │  <-- Main logic that sends response
└──────┬────────┘
       │
┌──────▼────────┐
│ HTTP Response │
└───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Request Flow Basics

Concept: Requests come into the server and are handled by specific functions called handlers.

When a user visits a website or calls an API, their request travels to the server. The server has handlers that decide what to do with each request, like sending back a webpage or data.

Result

Requests reach handlers that produce responses.

Understanding that handlers are the final step in request processing sets the stage for seeing why something might need to happen before them.

2

Foundation

What Middleware Is and Does

Concept: Middleware is code that runs before handlers to do common tasks on requests.

Middleware functions receive the request first. They can log info, check if a user is logged in, or change request data before passing it on. If middleware finds a problem, it can stop the request early.

Result

Middleware can modify or block requests before handlers run.

Knowing middleware runs first explains how it can prepare or protect the system before main logic runs.

3

Intermediate

Middleware Ordering and Execution

🤔Before reading on: Do you think middleware runs after handlers or before? Commit to your answer.

Concept: Middleware always runs before handlers to ensure requests are ready or safe.

NestJS calls middleware in the order they are registered. Each middleware can pass control to the next or stop the chain. Only after all middleware finish does the handler run.

Result

Middleware forms a chain that processes requests first, then handlers respond.

Understanding the order clarifies why middleware can enforce rules or add data before handlers see the request.

4

Intermediate

Common Middleware Uses in NestJS

🤔Before reading on: Which tasks do you think middleware handles? Logging, authentication, or response formatting? Commit to your answer.

Concept: Middleware handles tasks like logging, authentication, and parsing before handlers.

Middleware can log request details for debugging, check if a user is authenticated to protect routes, or parse JSON bodies so handlers get clean data.

Result

Handlers receive requests that are already checked and prepared.

Knowing middleware handles these tasks helps keep handlers focused on business logic, improving code clarity.

5

Advanced

Middleware vs Guards and Interceptors

🤔Before reading on: Do you think middleware and guards run at the same time or different stages? Commit to your answer.

Concept: Middleware runs before handlers, while guards and interceptors run at different points in request processing.

Guards run after middleware but before handlers to decide if a request can proceed. Interceptors wrap around handlers to modify responses or handle errors. Middleware prepares requests early, guards protect routes, interceptors enhance responses.

Result

Middleware is the earliest step in request processing, setting the stage for guards and interceptors.

Understanding these layers helps design secure and maintainable applications by placing logic in the right phase.

6

Expert

Internal NestJS Middleware Execution Flow

🤔Before reading on: Do you think NestJS middleware runs synchronously or can it handle async operations? Commit to your answer.

Concept: NestJS middleware runs in a chain, supporting both synchronous and asynchronous operations before handlers.

NestJS builds a middleware chain for each route. Each middleware calls next() to pass control. Middleware can perform async tasks like database checks before calling next(). Only after all middleware call next() does the handler execute.

Result

Middleware can perform complex async preparation without blocking the whole server.

Knowing middleware supports async lets developers handle real-world tasks like authentication checks efficiently before handlers.

Under the Hood

NestJS registers middleware functions in an internal list for each route. When a request arrives, NestJS calls each middleware in order. Each middleware receives the request, response, and a next function. Calling next() passes control to the next middleware or finally to the handler. Middleware can modify the request or response objects or end the response early. This chain mechanism allows flexible, layered processing before the handler runs.

Why designed this way?

Middleware was designed to separate concerns and avoid repeating code in handlers. Early web frameworks introduced middleware to handle cross-cutting concerns like logging and authentication uniformly. NestJS adopted this pattern to keep handlers clean and focused. The chain design allows flexible composition and asynchronous operations, which are essential for modern web apps.

┌───────────────┐
│ HTTP Request  │
└──────┬────────┘
       │
┌──────▼────────┐
│ Middleware 1  │
│ (e.g., Logger)│
└──────┬────────┘
       │ next()
┌──────▼────────┐
│ Middleware 2  │
│ (e.g., Auth)  │
└──────┬────────┘
       │ next()
┌──────▼────────┐
│ Request       │
│ Handler       │
└──────┬────────┘
       │
┌──────▼────────┐
│ HTTP Response │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does middleware run after the handler sends a response? Commit yes or no.

Common Belief: Middleware runs after the handler to modify the response.

Reality: Middleware runs before the handler and cannot modify the response after it is sent.

Why it matters: Thinking middleware runs after handlers can cause bugs where developers try to change responses too late, leading to errors or ignored changes.

Quick: Can middleware replace handlers entirely? Commit yes or no.

Common Belief: Middleware can fully handle requests and send responses instead of handlers.

Reality: Middleware can end a request early by sending a response, but its main role is to prepare requests for handlers, not replace them.

Why it matters: Misusing middleware as handlers can make code confusing and break NestJS conventions, reducing maintainability.

Quick: Does middleware run only once per application or per request? Commit your answer.

Common Belief: Middleware runs once when the app starts.

Reality: Middleware runs on every matching request, processing each request individually before handlers.

Why it matters: Assuming middleware runs once can cause developers to put request-specific logic in the wrong place, leading to bugs and security issues.

Quick: Is middleware execution order random or predictable? Commit your answer.

Common Belief: Middleware order does not matter; they run in any order.

Reality: Middleware runs in the order they are registered, which is critical for correct behavior.

Why it matters: Ignoring middleware order can cause security checks to run too late or logging to miss important info, leading to subtle bugs.

Expert Zone

1

Middleware can short-circuit the request by not calling next(), effectively ending the request early with a response.

2

Middleware runs before guards, so it cannot enforce authorization but can prepare data guards rely on.

3

Async middleware must always call next() or end the response to avoid hanging requests, a common source of bugs.

When NOT to use

Middleware is not suitable for fine-grained authorization or response transformation; use guards for authorization and interceptors for response handling instead.

Production Patterns

In production, middleware is used for logging requests, parsing JSON bodies, handling CORS, and verifying authentication tokens before handlers execute business logic.

Connections

Operating System Interrupt Handlers

Middleware acts like interrupt handlers that process signals before the main program runs.

Understanding middleware as a pre-processing layer is similar to how OS interrupts handle events before the main CPU instructions, showing layered control flow.

Assembly Line Manufacturing

Middleware is like quality control stations on an assembly line that check and prepare products before final assembly.

Seeing middleware as checkpoints helps understand its role in ensuring requests meet standards before final processing.

Event Bubbling in Web Browsers

Middleware chaining resembles event bubbling where events pass through layers before reaching the target.

Knowing event bubbling clarifies how middleware passes control along a chain, allowing layered handling.

Common Pitfalls

#1 Middleware does not call next(), causing requests to hang.

Wrong approach:

function middleware(req, res, next) {
// forgot to call next()
console.log('Request received');
}

Correct approach:

function middleware(req, res, next) {
console.log('Request received');
next();
}

Root cause:

Forgetting to call next() stops the request chain, so handlers never run and the client waits forever.

#2 Trying to modify response after handler sent it.

Wrong approach:

function middleware(req, res, next) {
next();
res.send('Modified response'); // too late
}

Correct approach:

function middleware(req, res, next) {
res.setHeader('X-Custom', 'value');
next();
}

Root cause:

Middleware runs before handlers; modifying response after sending is impossible and causes errors.

#3 Registering middleware in wrong order causing security checks to run late.

Wrong approach:

app.use(loggingMiddleware);
app.use(authMiddleware); // runs after logging

Correct approach:

app.use(authMiddleware);
app.use(loggingMiddleware); // auth runs first

Root cause:

Middleware order matters; security checks must run before logging or other middleware to protect data.

Key Takeaways

Middleware runs before request handlers to prepare, check, or modify requests.

It acts as a gatekeeper ensuring requests are safe and ready for main logic.

Middleware runs in a chain, and order of registration controls execution sequence.

Middleware supports asynchronous operations and can end requests early if needed.

Understanding middleware placement helps build secure, maintainable NestJS applications.