Why interceptors add cross-cutting logic in NestJS - Visual Breakdown

Concept Flow - Why interceptors add cross-cutting logic

Request Received

↓

Interceptor Runs Before

↓

Controller Handles Request

↓

Interceptor Runs After

↓

Response Sent

Interceptors run code before and after the main request handler, letting you add shared logic around many requests.

Execution Sample

NestJS

async intercept(context, next) {
  console.log('Before');
  const result = await next.handle().toPromise();
  console.log('After');
  return result;
}

This interceptor logs messages before and after the controller handles the request.

Execution Table

Step	Action	Output/Effect
1	Request arrives, interceptor intercepts	Logs 'Before'
2	Interceptor calls next.handle() to continue	Controller processes request
3	Controller returns response	Response captured by interceptor
4	Interceptor logs 'After'	Logs 'After'
5	Interceptor returns response	Response sent to client

💡 Interceptor finishes after controller response is handled and returned

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
result	undefined	undefined	Promise pending	Resolved response data	Returned response data

Key Moments - 2 Insights

Why does the interceptor run code both before and after the controller?

Because interceptors wrap the controller call, they can add logic before calling next.handle() and after awaiting it, as shown in steps 1 and 4 of the execution_table.

What happens if the interceptor does not call next.handle()?

The controller never runs, so the request is blocked. This is clear in step 2 where next.handle() triggers controller execution.

Visual Quiz - 3 Questions

Look at the execution_table, what is logged first when a request arrives?

A 'After'

B 'Before'

C Controller response

D Nothing

💡 Hint

Check Step 1 in the execution_table where the interceptor logs 'Before'

At which step does the controller actually process the request?

A Step 1

B Step 4

C Step 2

D Step 5

💡 Hint

Step 2 shows the interceptor calling next.handle(), which triggers the controller

If the interceptor skipped logging 'After', which step would change?

A Step 4

B Step 1

C Step 3

D Step 5

💡 Hint

Step 4 is where 'After' is logged by the interceptor

Concept Snapshot

Interceptors wrap controller calls to add shared logic.
They run code before and after the controller.
Use next.handle() to continue to the controller.
Useful for logging, timing, error handling.
They add cross-cutting logic without changing controllers.

Full Transcript

Interceptors in NestJS add cross-cutting logic by running code before and after the main controller handles a request. When a request arrives, the interceptor first runs its 'before' code, then calls next.handle() to let the controller process the request. After the controller returns a response, the interceptor runs its 'after' code and finally returns the response to the client. This wrapping behavior allows interceptors to add shared features like logging or timing around many requests without changing each controller. The execution table shows the step-by-step flow: logging 'Before', calling the controller, receiving the response, logging 'After', and sending the response. Variables like the response result change from undefined to resolved data as the interceptor awaits the controller. Key points include that interceptors must call next.handle() to continue processing, and they can run code both before and after the controller. This pattern helps keep code clean and reusable.