NestJS - Request Lifecycle

Which order best represents the NestJS HTTP request lifecycle for a successful request?

• Pipes → Guards → Middleware → Controller → Interceptors

• Middleware → Pipes → Guards → Controller → Interceptors

• Middleware → Guards → Interceptors (before) → Pipes → Controller/Handler → Interceptors (after) → Response

• Guards → Middleware → Pipes → Controller → Interceptors

Answer explanation

Nest first runs middleware, then guards (authorization), then interceptors (pre), then pipes (validation/transformation), then the handler, then interceptors (post), finally writing the response.

You need to reject unauthenticated requests before expensive DTO validation and body parsing. Where do you put the logic?

• Pipe

• Guard

• Interceptor

• Exception filter

Answer explanation

Guards run before pipes and short-circuit requests early, ideal for auth/authz checks.

What does this controller do in the lifecycle?

• Validates and transforms dto after the handler returns

• Validates and transforms dto before entering the handler

• Only transforms dto, never validates

• Skips global pipes

Answer explanation

Pipes (method-scoped here) run before the handler, validating and (optionally) transforming inputs.

You want to log latency and also map the handler result into a consistent { data, meta } envelope. Which components fit best?

• Single interceptor that times the call and maps the response

• Pipe that times the call and maps the response

• Two interceptors composed: one for timing, one for mapping

• Guard for timing, interceptor for mapping

• Exception filter for timing

Answer explanation

Interceptors can measure pre/post handler execution and shape responses. Pipes validate/transform inputs, not outputs.

About exception filters:

• They catch exceptions thrown anywhere including middleware

• A method-scoped filter only applies to that route handler

• Global filters can be overridden by controller-scoped filters

• Filters can format framework/unknown errors into HTTP responses

• Filters run before guards

Answer explanation

Filters catch exceptions after the handler (and inside the Nest context). Classic Express middleware errors aren’t caught unless integrated. Scope matters; more specific scopes take precedence for that route.

Where is userId resolved in the lifecycle?

• ParseIntPipe runs after the handler

• ParseIntPipe runs before the handler; header extraction is simple mapping

• ParseIntPipe and header extraction are both interceptors

• Both happen in guards

Answer explanation

Pipes validate/transform route params before the handler. Basic header extraction is parameter resolution; no pipe here.

You need to attach the authenticated user to the request so it’s visible to services via a request-scoped provider. Best approaches:

• In a guard, validate and set request.user = payload

• In an interceptor, mutate request.user after the handler

• Use @Inject(REQUEST) in a REQUEST-scoped provider to read user

• Use a pipe to inject user into DTO

• Create a global filter to set request.user on success

Answer explanation

Guards populate request context before handler; REQUEST-scoped providers can inject the REQUEST to access it. Pipes shape inputs, not ambient context.

You’re building a rate limiter that must: (1) read IP/headers, (2) reject early, (3) wrap the handler to add Retry-After when throttled. Where do you put logic?

• All in a single guard

• All in a single interceptor

• Guard to decide, interceptor to decorate response

• Pipe for counting, filter for response

Answer explanation

Use a guard to early-reject (cheap). Use an interceptor to add/shape response headers when allowing or when mapping throttling results.

About request-scoped providers:

• They’re instantiated per request, increasing memory/CPU

• They can inject REQUEST to get headers/user/trace id

• They’re the default scope for providers

• They’re ideal for pure stateless services used everywhere

• They can be combined with transient providers

Answer explanation

Request scope is per request, useful when you must carry request context; it’s not the default (singleton is), and don’t use it for ubiquitous stateless services.

Which is true?

• CacheInterceptor can cache the final transformed response

• ParseIntPipe runs after the cache lookup

• Global pipe will strip unknown fields on the response

• If the cache hits, ParseIntPipe still runs

• Guards would run after the cache check

Answer explanation

Interceptors (like CacheInterceptor) wrap handler responses. Param pipes run after interceptors’ pre-stage; cache lookup happens first. Global validation pipes affect incoming data, not outgoing responses.