Interceptors omhullen de uitvoering van een route handler, zodat je logica voor en na kan uitvoeren — en het request of response kunt transformeren. Ze zijn geïnspireerd door aspect-oriented programming en zijn ideaal voor cross-cutting concerns zoals logging, response transformatie, caching en timing.
()
{
(: , : ): <> {
.();
now = .();
next.().(
( .()),
);
}
}
Een interceptor implementeert intercept(). Code voor next.handle() wordt voor de handler uitgevoerd; next.handle() geeft een RxJS Observable van het response terug, en operators zoals tap/map laten je op het response reageren nadat de handler klaar is.
@Injectable()
export class TransformInterceptor implements NestInterceptor {
intercept(context: ExecutionContext, next: CallHandler) {
return next.handle().pipe(
map(data => ({ success: true, data, timestamp: new Date().toISOString() })),
// wraps EVERY response in a consistent envelope: { success, data, timestamp }
);
}
}
Met map kan een interceptor elk response herstructureren — bijv. alle responses in een standaard envelope wikkelen, een zeer gebruikelijk patroon voor consistente API responses.
// caching — return a cached response, skipping the handler entirely
// timeout — fail requests taking too long
return next.handle().pipe(timeout(5000));
// error mapping — transform exceptions
return next.handle().pipe(catchError(err => throwError(() => new BadGatewayException())));
// excluding fields (serialization) — ClassSerializerInterceptor strips @Exclude() fields
Common interceptor uses:
✓ Logging / timing requests (before + after)
✓ Transforming responses (consistent envelopes, field exclusion)
✓ Caching responses
✓ Adding timeouts
✓ Mapping/handling errors
@UseInterceptors(LoggingInterceptor) // method or controller level
app.useGlobalInterceptors(new TransformInterceptor()); // global
Middleware → runs BEFORE everything, with raw req/res (can't easily touch the response)
Guard → AUTHORIZATION decision (allow/block) before the handler
Interceptor → wraps the handler — runs BEFORE and AFTER, can TRANSFORM the response
Het definiërende kenmerk: interceptors kunnen logica na de handler uitvoeren en het response transformeren — wat middleware en guards niet schoon kunnen doen.
Interceptors zijn een krachtig NestJS-feature voor het elegant afhandelen van cross-cutting concerns, en hun onderscheidende mogelijkheid — logica zowel voor als na de handler uitvoeren en het response transformeren — maakt ze het juiste hulpmiddel voor behoeften die middleware en guards niet kunnen aanpakken.
Het begrijpen van interceptors is belangrijk omdat veel voorkomende vereisten natuurlijk op interceptors aansluiten: consistente response formatting (alle responses in een standaard { success, data } envelope wikkelen), logging/timing (handler duration meten), caching (gecachde responses teruggeven), timeouts, error transformatie en serialisatie (gevoelige velden uitsluiten).
Het kennen van de structuur (de next.handle() Observable, met tap/map/catchError om voor/na op te treden), de veel voorkomende use cases, en vooral hoe interceptors verschillen van middleware en guards (de mogelijkheid om het response in te pakken en te transformeren) is een belangrijk onderdeel van NestJS architectonische competentie.
Interceptors houden cross-cutting logica DRY en gecentraliseerd in plaats van duplicaat over handlers heen, waardoor ze een veel gebruikt, belangrijk hulpmiddel zijn voor het bouwen van schone, onderhoudbare NestJS applicaties.