Bird
Raised Fist0
NestJSframework~30 mins

Interceptor interface in NestJS - Mini Project: Build & Apply

Choose your learning style10 modes available
Creating a Logging Interceptor with NestJS Interceptor Interface
📖 Scenario: You are building a NestJS backend application. You want to log every incoming request and outgoing response to help with debugging and monitoring.
🎯 Goal: Create a simple logging interceptor using the NestJS Interceptor interface that logs the request method and URL before the request is handled, and logs the response data after the request is processed.
📋 What You'll Learn
Create a class called LoggingInterceptor that implements the NestInterceptor interface
Add a intercept method with parameters context and next
Inside intercept, log the HTTP method and URL from the request
Use next.handle() to continue the request processing
Use tap operator from rxjs to log the response data
Export the LoggingInterceptor class
💡 Why This Matters
🌍 Real World
Logging interceptors help developers monitor API usage and debug issues by tracking requests and responses in real time.
💼 Career
Understanding interceptors is essential for backend developers working with NestJS to implement cross-cutting concerns like logging, caching, and authentication.
Progress0 / 4 steps
1
Import required modules and create LoggingInterceptor class
Import Injectable, NestInterceptor, ExecutionContext, and CallHandler from @nestjs/common. Also import Observable from rxjs. Create an exported class called LoggingInterceptor that implements NestInterceptor.
NestJS
Hint

Start by importing the necessary NestJS interfaces and create the class with the correct name and interface.

2
Extract HTTP request method and URL from ExecutionContext
Inside the intercept method, create a constant called request by calling context.switchToHttp().getRequest(). Then create constants method and url from request.method and request.url respectively.
NestJS
Hint

Use context.switchToHttp().getRequest() to get the HTTP request object, then get method and url from it.

3
Log request info and use next.handle() with tap to log response
Inside intercept, log the string `Incoming Request: ${method} ${url}` using console.log. Then return next.handle() piped with tap from rxjs/operators that logs `Response: ${JSON.stringify(data)}` where data is the response.
NestJS
Hint

Use console.log to log the request info. Use next.handle().pipe(tap(...)) to log the response data.

4
Add @Injectable decorator and export the class
Make sure the LoggingInterceptor class is decorated with @Injectable() and is exported. This completes the interceptor implementation.
NestJS
Hint

Check that @Injectable() is above the class and the class is exported.

Practice

(1/5)
1. What is the primary purpose of an interceptor in NestJS?
easy
A. To run code before and after a request is handled
B. To define database schemas
C. To handle HTTP routing
D. To manage user authentication

Solution

  1. Step 1: Understand the role of interceptors

    Interceptors in NestJS are designed to execute code before and after the main request handler runs.
  2. Step 2: Compare with other options

    Database schemas, routing, and authentication are handled by other parts of NestJS, not interceptors.
  3. Final Answer:

    To run code before and after a request is handled -> Option A
  4. Quick Check:

    Interceptor purpose = run code before/after request [OK]
Hint: Interceptors wrap request handling with extra code [OK]
Common Mistakes:
  • Confusing interceptors with middleware
  • Thinking interceptors handle routing
  • Assuming interceptors manage authentication
2. Which method must be implemented when creating a NestJS interceptor?
easy
A. handle()
B. intercept()
C. execute()
D. process()

Solution

  1. Step 1: Recall the interceptor interface

    The NestJS interceptor interface requires implementing the intercept() method.
  2. Step 2: Verify other options

    Methods like handle(), execute(), or process() are not part of the interceptor interface.
  3. Final Answer:

    intercept() -> Option B
  4. Quick Check:

    Interceptor method = intercept() [OK]
Hint: Remember: intercept() runs your interceptor logic [OK]
Common Mistakes:
  • Using handle() instead of intercept()
  • Confusing with middleware method names
  • Forgetting to implement intercept()
3. Given this interceptor code snippet, what will be logged?
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'))
    );
  }
}
medium
A. Only 'Before handler' is logged
B. Only 'After handler' is logged
C. 'Before handler' then 'After handler' are logged
D. No logs are produced

Solution

  1. Step 1: Analyze the intercept method

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

    The tap operator logs 'After handler' when the Observable emits after the request handler finishes.
  3. Final Answer:

    'Before handler' then 'After handler' are logged -> Option C
  4. Quick Check:

    Logs before and after handler = 'Before handler' then 'After handler' are logged [OK]
Hint: tap() logs after the handler completes [OK]
Common Mistakes:
  • Thinking only one log appears
  • Ignoring the Observable pipe behavior
  • Assuming synchronous logging only
4. What is wrong with this interceptor implementation?
import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class ErrorInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    try {
      return next.handle();
    } catch (error) {
      console.error('Error caught:', error);
      throw error;
    }
  }
}
medium
A. The interceptor should not throw errors
B. The intercept method must return void, not Observable
C. Missing call to next.handle() inside try block
D. The try-catch block won't catch async errors from next.handle()

Solution

  1. Step 1: Understand async error handling in interceptors

    next.handle() returns an Observable, so errors happen asynchronously and are not caught by try-catch.
  2. Step 2: Identify the problem with the try-catch

    The try-catch only catches synchronous errors, so async errors must be handled with RxJS operators like catchError.
  3. Final Answer:

    The try-catch block won't catch async errors from next.handle() -> Option D
  4. Quick Check:

    Async errors need RxJS catchError, not try-catch [OK]
Hint: Use RxJS catchError for async errors, not try-catch [OK]
Common Mistakes:
  • Using try-catch for async Observable errors
  • Assuming intercept returns void
  • Not handling errors inside pipe
5. You want to create an interceptor that measures how long a request takes and adds this duration to the response object as response.duration. Which approach correctly implements this?
hard
A. Record start time, call next.handle(), then use tap() to calculate duration and modify response before returning
B. Record start time, use try-catch around next.handle(), then set duration after catch
C. Modify response before calling next.handle(), then record duration after
D. Use a middleware instead of interceptor to measure time

Solution

  1. Step 1: Understand timing with interceptors

    Start time must be recorded before calling next.handle(), which returns an Observable.
  2. Step 2: Use tap() to run code after handler finishes

    tap() lets you calculate duration after the response is ready and modify it safely.
  3. Step 3: Evaluate options

    Record start time, call next.handle(), then use tap() to calculate duration and modify response before returning correctly uses tap() after next.handle() to set response.duration. Record start time, use try-catch around next.handle(), then set duration after catch uses try-catch incorrectly for async. Modify response before calling next.handle(), then record duration after modifies response too early. Use a middleware instead of interceptor to measure time suggests middleware, which is not the question focus.
  4. Final Answer:

    Record start time, call next.handle(), then use tap() to calculate duration and modify response before returning -> Option A
  5. Quick Check:

    Use tap() after next.handle() to measure time [OK]
Hint: Use tap() after next.handle() to add timing info [OK]
Common Mistakes:
  • Trying to catch async errors with try-catch
  • Modifying response before handler runs
  • Confusing middleware with interceptor roles
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