Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
NestJS normally processes a request through middleware, guards, inbound interceptors, pipes, the controller handler, and then the interceptors’ response path. If an uncaught exception occurs, normal processing stops and Nest looks for an applicable exception filter. Knowing this order helps pinpoint where authentication, authorization, validation, response handling, and error formatting belong.
NestJS request lifecycle cheat sheet
Incoming request
→ Middleware
→ Guards: global → controller → route
→ Interceptors enter: global → controller → route
→ Pipes: global → controller → route → parameter-level
→ Controller handler (and any service work it calls)
→ Interceptors unwind: route → controller → global
→ Server responseThis is the usual route through NestJS, not a requirement that every application use every component. Middleware, guards, and interceptors can pass control onward or stop it; a controller does not have to call a service. An uncaught exception diverts processing to an applicable exception filter instead of following the ordinary success path. See Nest’s request lifecycle FAQ.
What each component does—and where it fits
Middleware: before route handling
Middleware runs before Nest proceeds to route-specific handling. It can access the request, response, and next() function, making it useful for request-level setup that does not depend on the selected controller handler—for example, establishing request context or attaching identity information to the request.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Nest supports function-based and class-based middleware. Module-bound middleware is configured in a module’s configure() method with MiddlewareConsumer. Middleware runs sequentially in binding order: globally bound middleware first, followed by matching module-bound middleware. The FAQ further describes module ordering as global modules first, then the root module, then other modules by distance from the root in the import graph.
#1 Best Overall
Middleware must either end the response or call next() to pass control along; otherwise, the request hangs. Because middleware runs before a route has been selected, only global exception filters apply to middleware errors. Middleware signatures and behavior can also differ between the Express and Fastify adapters. See the NestJS middleware documentation.
Guards: decide whether a route may proceed
Guards run after all middleware and before any interceptor or pipe. A guard implements CanActivate and can return a boolean, a Promise, or an Observable. A truthy permission result allows processing to continue; a denial prevents the handler from proceeding.
Unlike middleware, a guard receives ExecutionContext, so it can inspect the target handler and execution context. That makes guards a natural place for route-aware authentication or authorization decisions, such as checking roles or permissions. Binding order is global, controller, then route, with guards running in the order bound at each level. See the NestJS guards documentation.
Interceptors: wrap handler execution and its result
An interceptor’s intercept() method receives an ExecutionContext and a CallHandler. Calling next.handle() produces an RxJS Observable for the handler’s result. Code before that stream is the inbound leg; operators on the stream can observe or transform values and handle errors on the way back.
Rank #3
Interceptors nest: the inbound order is global, controller, route, while the response path unwinds route, controller, global. This explains why logs or other side effects can appear in the opposite order before and after a handler. Interceptors can also short-circuit handler execution—for example, by returning a cached Observable—or transform results and exceptions. The Nest FAQ notes that an interceptor can catch errors originating in pipes, controllers, or services.
A successful-value callback such as tap(nextValue) does not run when the handler throws. Use an error callback or finalize() when error observation or cleanup must also occur on failure. See the NestJS interceptors documentation.
Pipes: validate or transform arguments before invocation
Pipes run immediately before the controller method is called and operate on handler arguments. A validation pipe can accept valid input or throw an exception; a transformation pipe can convert input, such as a path string into an integer. If a pipe throws, the handler does not run. As Nest puts it, “Pipes run inside the exceptions zone.” See the NestJS pipes documentation.
Common built-in pipes include ValidationPipe, StandardSchemaValidationPipe, ParseIntPipe, ParseFloatPipe, ParseBoolPipe, ParseArrayPipe, ParseUUIDPipe, ParseEnumPipe, DefaultValuePipe, ParseFilePipe, and ParseDatePipe. Applying parsing and validation at the input boundary keeps handlers from having to repeat that work.
Best Value
Controller handler and service work
Once guards allow the request and pipes produce acceptable arguments, Nest invokes the controller’s route method. The method may call a service or other provider, but Nest does not automatically insert service work into every request lifecycle.
Exception filters: handle uncaught exceptions
Exception filters are not a routine final stage for successful requests. When an uncaught exception occurs, Nest skips the rest of the ordinary lifecycle and checks for a filter, starting with the most local applicable binding: route, then controller, then global. If a route-level filter handles an exception, Nest does not pass that handled exception on to controller-level or global filters. Middleware errors are a special case: because the route has not been selected yet, only global filters apply. See the NestJS exception filters documentation and the request lifecycle FAQ.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How scope changes execution order
For guards, interceptors, and pipes, binding scope determines the order across the application: global, controller, then route. Interceptors reverse that nesting after handler execution, unwinding route, controller, then global. Middleware has its own sequential binding and module ordering, while exception filters are selected from the most local applicable scope outward.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
There is also a parameter-order detail for pipes. In the FAQ’s example with handler parameters named body, params, and query, parameters are processed from last to first: query, params, then body. A controller-level pipe processes that sequence, followed by the route-level pipe processing the same sequence.
Trace a request when something goes wrong
- Confirm middleware passes control. Check that each middleware either ends the response intentionally or calls
next(). Verify its binding and path match. - Check guard decisions. Guards run after middleware but before interceptors and pipes. A denied request will not reach the handler.
- Inspect interceptor entry and exit separately. Entry is global → controller → route; response handling unwinds route → controller → global. If the handler throws, a success-only callback will not observe a value.
- Check pipe errors before debugging handler logic. A failing validation or transformation prevents the controller method from running. For an invalid
:id, for example,ParseIntPipecan reject the value before a method such asfindOne()is invoked. - Identify which filter can see the exception. For route-aware failures, check route, controller, then global filters. For an error thrown in middleware, check the global filter; a route or controller filter cannot apply before route selection.
Where to put common request work
- Request-level setup without route context: middleware.
- Route-aware access decisions: guards.
- Input parsing and validation: pipes.
- Wrapping, observing, or transforming handler results and errors: interceptors.
- Formatting uncaught exceptions: exception filters.
The lifecycle order and caveats here reflect the official NestJS documentation retrieved on October 7, 2026. The FAQ page does not state a framework version, so this explanation does not assign one.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
