Topic

Middleware vs guards vs pipes

Definition

Nest processes an incoming request through ordered extension points — middleware, guards, interceptors, and pipes — where each stage has full access to different information and a distinct, narrow responsibility.

In simpler words

Middleware runs first and knows nothing about routes; guards decide who may proceed; pipes clean up and validate the data the handler will receive.

Correlation ids, JWT/role checks, and DTO validation look similar — “code that runs before my controller” — but belong in different stages for a reason.

Open official example (opens in new tab)

After this you can

Order middleware, guards, and pipes in the request pipeline
Explain why middleware cannot read @Roles or @Public
Choose the right stage for a new cross-cutting check

Where each stage sits in the pipeline

Definition

Middleware executes before Nest resolves a route handler and its metadata, guards execute afterward with full execution-context access, and pipes execute per parameter to transform or validate arguments just before the handler runs.

In simpler words

Middleware cannot see @Roles or @Public; guards can. Pipes see one argument at a time, not the whole request.

Rough order: Middleware → Guards → Interceptors (before) → Pipes → Controller handler → Interceptors (after) → Exception filters.

CorrelationIdMiddleware runs for every matched path via consumer.apply(...).forRoutes("*") — it cannot make an authorization decision because guards, and the route metadata they read, do not exist yet at that point.

Correlation id middleware

const correlationId = req.header('x-correlation-id') ?? randomUUID();
req.correlationId = correlationId;
res.setHeader('x-correlation-id', correlationId);
next();

Cross-cutting and stateless — a good middleware job. It never reads @Roles or user identity.

Choosing the right tool for a new check

Definition

A new cross-cutting request concern belongs in middleware only when it needs no route metadata and no per-argument transformation, in a guard when it depends on route metadata or the authenticated subject, and in a pipe when it validates or reshapes one specific argument.

In simpler words

Ask: does this need the route’s decorators (guard), just one incoming value (pipe), or neither (middleware)?

ValidationPipe is registered globally in main.ts and runs for every DTO-typed parameter — it is what turns CreateTicketDto’s decorators into an actual 400 response.

ParseUUIDPipe on :id params is a pipe too: it rejects a malformed id before TicketsService ever runs a query.

Three stages, one request

GET /tickets/not-a-uuid
// Middleware: attaches correlation id, calls next()
// Guards: JwtAuthGuard confirms the session, RolesGuard allows (no @Roles here)
// Pipe: ParseUUIDPipe rejects 'not-a-uuid' -> 400 before the handler runs

Each stage rejects or passes the request for a different reason — none of them duplicate the others’ job.

Keep in mind

Middleware: cross-cutting, stateless, no route metadata.
Guards: authentication and authorization, route-metadata aware.
Pipes: per-argument validation and transformation, closest to the handler.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. What runs first among middleware, guards, and pipes?

Concept

Guards, then middleware, then pipes before the handlerMiddleware, then guards, then pipes before the handlerPipes, then middleware, then guards before the handlerMiddleware, then pipes, then guards before the handler

2. Can middleware read @Roles like a guard?

Syntax

Not with the same ExecutionContext/Reflector ergonomics guards haveYes — middleware receives the same ExecutionContext as guardsYes — inject Reflector into middleware to read handler metadataYes — @Roles is attached to the request object for middleware

3. Are guards and pipes interchangeable for DTO validation?

Practical

No — pipes validate arguments; guards authorizeYes — either can validate DTOs the same wayYes — pipes authorize rolesYes — guards transform query strings into numbers only

4. What is CorrelationIdMiddleware for?

Logic

Generate a correlation id after the handler returns for the response bodyAttach a request correlation id early for logs/errorsAttach the authenticated user id to the request before guardsTrace database queries by injecting an id into TypeORM

5. When do pipes validate @Body DTOs?

Concept

Right before the handler, after guardsBefore guards, so malformed requests never reach authenticationInside the middleware layer, before guards runAfter the handler returns, to validate the response body

6. Why put authz in guards not earliest middleware?

Practical

Middleware runs after guards, so it is too late to blockMiddleware cannot access the request object, only the responseGuards have clean access to route handler metadata via ReflectorGuards run once at startup, so the check is cached

7. What does ValidationPipe whitelist do?

Syntax

Strip properties not decorated on the DTOReject any request that includes extra fieldsAllow only whitelisted origins through CORSKeep only properties that pass their validators, dropping invalid ones

8. What does forbidNonWhitelisted do?

Logic

Silently strip unknown properties from the DTOReject requests missing any required propertyForbid non-admin users from sending a bodyReject requests that send unknown properties

9. Can middleware end the response?

Concept

No — only guards may throw to end a requestNo — middleware must always call next() to continueOnly if it is registered as an APP_GUARDYes — but authz/validation still usually belong in guards/pipes

10. Which layer transforms query limit strings to numbers?

Practical

A guard using Reflector to coerce query parametersThe @Query() decorator, which parses numbers automaticallyValidationPipe with transform:true on DTO fieldsCorrelationIdMiddleware, which normalizes query params early

11. For an unauthenticated request to a guarded route, does ValidationPipe run?

Conceptadvanced

app.useGlobalPipes(new ValidationPipe());
// a guard rejects unauthenticated requests

Yes — pipes always run first to sanitize inputYes — pipes and guards run in parallelNo — because pipes only run on GETNo — guards run before pipes, so the 401 happens before validation

12. With whitelist:true, what does the handler receive as the DTO?

Syntaxintermediate

new ValidationPipe({ whitelist: true });
// body: { title: 'Bug', isAdmin: true }

The full body including isAdminAn empty object because extra fields errorOnly decorated properties, e.g. { title: "Bug" } — isAdmin is strippednull, because unknown fields fail validation

13. Now with forbidNonWhitelisted:true, what happens to that same request?

Practicalintermediate

new ValidationPipe({ whitelist: true, forbidNonWhitelisted: true });
// body: { title: 'Bug', isAdmin: true }

isAdmin is silently stripped as beforeIt is rejected with 400 because it contains a non-whitelisted propertyIt succeeds and isAdmin is keptIt returns 403 Forbidden

14. With transform:true, what is limit inside the handler?

Logicadvanced

class ListDto { @IsInt() @Type(() => Number) limit: number; }
// GET /tickets?limit=20

The number 20, coerced by class-transformer via transform:trueThe string "20"; DTOs never coerce typesundefined, because query params are not validatedNaN, because @IsInt rejects strings

15. Why implement this as middleware rather than a guard?

Conceptintermediate

export class CorrelationIdMiddleware implements NestMiddleware {
  use(req, res, next) {
    req.correlationId = randomUUID();
    next();
  }
}

Guards cannot call next()Middleware is the only place that can read reqIt attaches request context early for all routes and makes no auth decisionBecause it must run after validation

Checking your session…