Why interceptors add cross-cutting logic in NestJS - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of interceptors in NestJS?

Interceptors in NestJS are often used to add cross-cutting logic. What does this mean in practice?

A They allow you to run code before and after method execution, affecting multiple parts of the app without changing each method.

B They replace the main logic of a controller method with a new implementation.

C They only handle errors thrown by controller methods.

D They are used to define database models and schemas.

💡 Hint

Think about how interceptors can wrap around method calls to add shared behavior.

Interceptors let you run code before and after method calls, so you can add shared features like logging or timing without changing each method.

❓ component_behavior

intermediate

How does an interceptor modify the response in NestJS?

Given an interceptor that logs the time taken by a method, what will be the output behavior?

NestJS

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';
import { tap } from 'rxjs/operators';

@Injectable()
export class TimingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const start = Date.now();
    return next.handle().pipe(
      tap(() => console.log(`Execution time: ${Date.now() - start}ms`))
    );
  }
}

A The interceptor blocks the response and only logs the time without returning anything.

B The interceptor changes the response to include the execution time as a new field.

C The interceptor logs the time before the method starts and returns an error.

D The interceptor logs the execution time after the method completes, then returns the original response unchanged.

💡 Hint

Look at when the tap operator runs in the observable pipeline.

The interceptor uses tap to log after the method finishes, but it does not modify the response data.

❓ lifecycle

advanced

When is the intercept method called in the NestJS request lifecycle?

At what point does the intercept method of a NestJS interceptor execute relative to controller method execution?

A Only after the controller method has completed and sent the response.

B Before the controller method is called and after it returns, wrapping the method execution.

C Only before the controller method is called, without access to the response.

D Only when an exception is thrown inside the controller method.

💡 Hint

Interceptors wrap around method calls like a sandwich.

The intercept method runs before and after the controller method, allowing it to modify or observe the process.

📝 Syntax

advanced

Which interceptor code correctly adds a header to the HTTP response?

Choose the correct NestJS interceptor code that adds a custom header 'X-Custom' with value 'Hello' to the response.

A

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';
import { tap } from 'rxjs/operators';

@Injectable()
export class HeaderInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const response = context.switchToHttp().getResponse();
    response.setHeader('X-Custom', 'Hello');
    return next.handle();
  }
}

B

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class HeaderInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const response = context.getResponse();
    response.headers['X-Custom'] = 'Hello';
    return next.handle();
  }
}

C

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class HeaderInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const response = context.switchToHttp().getResponse();
    response.header('X-Custom', 'Hello');
    return next.handle();
  }
}

D

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class HeaderInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const response = context.switchToHttp().getResponse();
    response.setHeaders({'X-Custom': 'Hello'});
    return next.handle();
  }
}

💡 Hint

Check the correct method name to set a single header on the response object.

The Express response object uses setHeader to add headers. Other methods like setHeaders do not exist or are incorrect.

🔧 Debug

expert

Why does this interceptor fail to log execution time?

Consider this interceptor code. It is supposed to log execution time but logs nothing. Why?

NestJS

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> {
    const start = Date.now();
    next.handle().subscribe(() => {
      console.log(`Execution time: ${Date.now() - start}ms`);
    });
    return next.handle();
  }
}

A The interceptor returns next.handle() before the subscription logs, so the log never executes.

B The console.log is inside subscribe but next.handle() is not subscribed properly, so it never runs.

C The interceptor should use tap operator instead of subscribe to log side effects correctly.

D Calling next.handle() twice causes the observable to run twice, but the first subscription logs nothing because it is not awaited.

💡 Hint

Think about how RxJS observables work and how side effects should be handled.

Calling next.handle() twice creates two separate observables. The subscription inside intercept is ignored because the returned observable is different. Using tap inside the pipe ensures the side effect runs on the same observable.