Bird
Raised Fist0
NestJSframework~30 mins

Why interceptors add cross-cutting logic in NestJS - See It in Action

Choose your learning style10 modes available
Why interceptors add cross-cutting logic
📖 Scenario: You are building a NestJS backend application that needs to log the time taken by each request and modify the response before sending it back.This is a common real-world need where you want to add behavior that applies to many parts of your app without changing each controller method.
🎯 Goal: Build a simple NestJS interceptor that adds cross-cutting logic to log request duration and modify the response message.
📋 What You'll Learn
Create a basic NestJS controller with one GET route returning a string
Create an interceptor class implementing NestInterceptor
Add logic in the interceptor to log the time taken for the request
Modify the response data in the interceptor before sending it back
Apply the interceptor to the controller route
💡 Why This Matters
🌍 Real World
In real backend applications, interceptors help add features like logging, caching, or transforming responses without repeating code in every controller method.
💼 Career
Understanding interceptors is important for backend developers working with NestJS or similar frameworks to write clean, maintainable, and scalable server-side code.
Progress0 / 4 steps
1
Create a basic NestJS controller
Create a NestJS controller class called AppController with a GET route method getHello that returns the string 'Hello World'.
NestJS
Hint

Use @Controller() decorator and define a method getHello with @Get() decorator returning the exact string.

2
Create an interceptor class
Create a class called LoggingInterceptor that implements NestInterceptor from @nestjs/common. Import CallHandler and ExecutionContext as well. Add an empty intercept method with parameters context: ExecutionContext and next: CallHandler returning next.handle().
NestJS
Hint

Implement the intercept method returning next.handle() to pass control to the next handler.

3
Add timing and response modification logic in interceptor
Inside the intercept method of LoggingInterceptor, record the current time before calling next.handle(). Use pipe with map from rxjs/operators to calculate elapsed time after the handler completes. Log the elapsed time with console.log. Modify the response by appending ' - Processed by interceptor' to the original data.
NestJS
Hint

Use Date.now() to get current time, then use pipe and map to modify the response and log elapsed time.

4
Apply the interceptor to the controller route
Import UseInterceptors from @nestjs/common. Add the decorator @UseInterceptors(LoggingInterceptor) above the getHello method in AppController to apply the interceptor to that route.
NestJS
Hint

Use the @UseInterceptors(LoggingInterceptor) decorator above the getHello method.

Practice

(1/5)
1. What is the main reason to use interceptors in NestJS?
Interceptors help to add logic that applies to many parts of the app without repeating code. Why is this useful?
easy
A. They add shared logic before and after main code, like logging or timing.
B. They replace controllers to handle HTTP requests directly.
C. They store data permanently in the database.
D. They generate frontend UI components automatically.

Solution

  1. Step 1: Understand the role of interceptors

    Interceptors run code before and after the main handler, allowing shared tasks like logging or error handling.
  2. Step 2: Compare with other options

    Controllers handle requests, databases store data, and UI components are unrelated to interceptors.
  3. Final Answer:

    They add shared logic before and after main code, like logging or timing. -> Option A
  4. Quick Check:

    Interceptors add shared logic = A [OK]
Hint: Interceptors wrap main code to add shared tasks [OK]
Common Mistakes:
  • Thinking interceptors handle HTTP requests directly
  • Confusing interceptors with database or UI roles
  • Assuming interceptors replace controllers
2. Which of the following is the correct way to implement an interceptor in NestJS?
easy
A. Implement the NestInterceptor interface and define the intercept() method.
B. Create a class with a handle() method and decorate it with @Controller().
C. Use @Injectable() on a service without any methods.
D. Write a function that returns a promise without any interface.

Solution

  1. Step 1: Recall NestJS interceptor pattern

    Interceptors must implement the NestInterceptor interface and define the intercept() method.
  2. Step 2: Check other options

    Controllers use @Controller() and handle() is not an interceptor method; services need methods; plain functions lack interface.
  3. Final Answer:

    Implement the NestInterceptor interface and define the intercept() method. -> Option A
  4. Quick Check:

    Interceptor interface + intercept() = B [OK]
Hint: Interceptors always implement NestInterceptor with intercept() [OK]
Common Mistakes:
  • Confusing interceptors with controllers or services
  • Missing the intercept() method
  • Not using the NestInterceptor interface
3. Given this interceptor code snippet:
import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable, tap } from 'rxjs';

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    console.log('Before handler');
    return next.handle().pipe(
      tap(() => console.log('After handler'))
    );
  }
}

What will be printed to the console when a request is handled?
medium
A. Only After handler
B. Before handler, then After handler
C. Only Before handler
D. No output printed

Solution

  1. Step 1: Analyze the intercept method flow

    The interceptor logs 'Before handler' immediately, then calls next.handle() which runs the main handler.
  2. Step 2: Understand the tap operator

    The tap operator runs after the main handler completes, logging 'After handler'.
  3. Final Answer:

    Before handler, then After handler -> Option B
  4. Quick Check:

    Logs before and after handler = C [OK]
Hint: Logs before then after main handler due to tap() [OK]
Common Mistakes:
  • Thinking only one log prints
  • Confusing order of logs
  • Ignoring the tap() operator effect
4. You wrote this interceptor but it does not log anything:
import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class SilentInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    console.log('Intercepted');
    next.handle();
  }
}

What is the problem?
medium
A. The import statements are incorrect.
B. The console.log statement is after next.handle(), so it never runs.
C. The class is missing the @Controller() decorator.
D. The intercept method does not return the observable from next.handle().

Solution

  1. Step 1: Check the intercept method return

    The intercept method must return the observable from next.handle() to continue the request flow.
  2. Step 2: Identify missing return

    Here, next.handle() is called but its result is not returned, so the request does not proceed and logs may not appear.
  3. Final Answer:

    The intercept method does not return the observable from next.handle(). -> Option D
  4. Quick Check:

    Missing return next.handle() = D [OK]
Hint: Always return next.handle() observable in intercept() [OK]
Common Mistakes:
  • Forgetting to return next.handle()
  • Misplacing console.log after next.handle()
  • Confusing decorators for interceptors
5. You want to measure the time taken by any request handler in your NestJS app. Which interceptor approach correctly adds this cross-cutting timing logic?
import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable, tap } from 'rxjs';

@Injectable()
export class TimingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const start = Date.now();
    return next.handle().pipe(
      tap(() => {
        const elapsed = Date.now() - start;
        console.log(`Request took ${elapsed}ms`);
      })
    );
  }
}
hard
A. This interceptor logs time but does not call next.handle(), so no handler runs.
B. This interceptor measures time only before the handler, missing after completion.
C. This interceptor correctly measures time before and after the handler using tap().
D. This interceptor should use setTimeout instead of tap() to measure time.

Solution

  1. Step 1: Understand timing measurement

    The interceptor records start time before calling next.handle() and uses tap() to run code after the handler completes.
  2. Step 2: Confirm correct usage of RxJS tap()

    The tap() operator runs side effects after the observable emits, so it correctly logs elapsed time after the request finishes.
  3. Final Answer:

    This interceptor correctly measures time before and after the handler using tap(). -> Option C
  4. Quick Check:

    Timing with tap() after handler = A [OK]
Hint: Use tap() after next.handle() to measure elapsed time [OK]
Common Mistakes:
  • Measuring time only before handler
  • Not returning next.handle() observable
  • Using setTimeout instead of RxJS operators
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard