NestJS Life Cycle Diagram

1. Incoming Request

The lifecycle begins when a client makes an HTTP request. This request enters the NestJS application and initiates the processing pipeline.

2. Middleware

Middleware functions run early in the lifecycle. They can perform actions like logging, request modification, or authentication checks. There are two types:

• Globally Bound Middleware:

  These run for every request coming into the application.

• Module Bound Middleware:

  These run only for requests that target routes within a specific module.

3. Guards

After middleware, the request is checked by guards. Guards are primarily used for authorization and access control. They determine whether a request should be allowed to continue based on defined conditions. Guards can be applied at three levels:

• Global Guards:

  Applied to every request throughout the application.

• Controller Guards:

  Applied to all routes within a specific controller.

• Route Guards:

  Applied to individual routes.

4. Interceptors (Pre-Controller)

Before the request reaches the controller, interceptors can modify or transform it. They are useful for logging, performance monitoring, and altering the flow of request processing. Interceptors are also structured in a three-level hierarchy:

• Global Interceptors:

  Affect all incoming requests.

• Controller Interceptors:

  Affect all routes in a specific controller.

• Route Interceptors:

  Affect individual routes.

5. Pipes

Once the request is nearing the controller, pipes handle data transformation and validation. Pipes can sanitize, transform, or validate the incoming data, ensuring it meets the necessary criteria before it’s processed further. They come in several flavors:

• Global Pipes:

  Applied to all requests.

• Controller Pipes:

  Applied to all routes within a controller.

• Route Pipes:

  Applied to specific routes.

• Route Parameter Pipes:

  Applied to specific parameters of a route handler.

6. Controller (Method Handler)

The request finally reaches the controller. The controller contains the endpoint logic (the method handler) that processes the request, orchestrates further actions, or calls services to perform business logic.

7. Service (if exists)

Within the controller, services may be called to handle complex business logic, data processing, or database interactions. This separation keeps the controller lightweight and focused on handling requests and responses.

8. Interceptors (Post-Request)

After the controller (and any associated services) has processed the request, another set of interceptors comes into play. These post-request interceptors can modify the outgoing response or add additional behavior such as logging or caching. They follow a similar hierarchy:

• Route Interceptors:

  Specific to the individual route.

• Controller Interceptors:

  Specific to a controller.

• Global Interceptors:

  Applied to all responses from the application.

9. Exception Filters

If any errors occur during processing, exception filters catch and handle them. They can customize error responses and log errors. Like other components, exception filters can be applied at different levels:

• Route Exception Filters:

  Specific to an individual route.

• Controller Exception Filters:

  Specific to a controller.

• Global Exception Filters:

  Handle exceptions application-wide.

10. Server Response

Finally, after all processing (or error handling), the response is sent back to the client. This concludes the lifecycle of the request.

Life Cycle Diagram