What is the NestJS request lifecycle order?

Question

Accepted Answer

The **request lifecycle** is the precise sequence of components a request passes through in NestJS — middleware, guards, interceptors, pipes, the handler, then interceptors again, and exception filters on errors. Knowing the exact order is crucial for understanding *when* each piece of logic runs.

## The full order

```text
Incoming Request
   │
   ▼
1. MIDDLEWARE            (Express-style; raw req/res; runs first)
   │
   ▼
2. GUARDS                (authorization — return true to continue, false/throw to block)
   │
   ▼
3. INTERCEPTORS (pre)    (logic BEFORE the handler — start timing, etc.)
   │
   ▼
4. PIPES                 (validate/transform the handler's arguments — DTO validation)
   │
   ▼
5. ROUTE HANDLER         (your controller method runs)
   │
   ▼
6. INTERCEPTORS (post)   (logic AFTER the handler — transform the response)
   │
   ▼
Response

✗ If an exception is thrown ANYWHERE above →
7. EXCEPTION FILTERS     (catch it and format the error response)
```

## Why the order matters (practical consequences)

```text
• Guards run BEFORE pipes → authorization is checked before input validation
  (no point validating a body for an unauthorized request)
• Pipes run JUST BEFORE the handler → the handler always gets validated/transformed args
• Interceptors straddle the handler → they can measure its duration and transform output
• Filters catch errors from any stage → centralized, consistent error handling
```

## Within each category, scope ordering applies

```text
For each type (guards, interceptors, pipes), they run in this scope order:
  Global → Controller → Method (route)
So a global guard runs before a controller-level guard, before a route-level guard.
```

## A concrete example

```ts
@Controller("users")
@UseGuards(AuthGuard)                    // 2. checks authorization
@UseInterceptors(LoggingInterceptor)     // 3 (pre) + 6 (post)
export class UsersController {
  @Post()
  create(@Body() dto: CreateUserDto) {    // 4. ValidationPipe validates dto, 5. handler runs
    return this.usersService.create(dto);
  }
}
// Flow: middleware → AuthGuard → LoggingInterceptor(before) → ValidationPipe →
//       create() → LoggingInterceptor(after) → response (or → filter on error)
```

## Why it matters

Understanding the request lifecycle order is fundamental to building NestJS applications correctly — it determines exactly *when* each piece of cross-cutting logic executes, which directly affects design decisions and debugging.

The ordering has real, practical significance: **guards run before pipes**, so authorization is correctly checked before bothering to validate input (an unauthorized request is rejected before validation); **pipes run just before the handler**, guaranteeing the handler always receives validated, transformed arguments; **interceptors wrap the handler** (running before *and* after), which is precisely what lets them time execution and transform responses; and **exception filters catch errors from any stage**, enabling centralized error handling.

Knowing this order — plus the within-category scope ordering (global → controller → method) — lets you place logic in the right component, predict execution flow, debug why something runs (or doesn't run) when expected, and architect features correctly.

It ties together all the framework's request-handling pieces (middleware, guards, interceptors, pipes, filters) into a coherent mental model, making it an important, frequently-tested topic that reflects genuine understanding of how NestJS processes requests.