Interceptors pakker udførelsen af en route handler ind, hvilket lader dig køre logik før og efter den — og transformere request eller response. De er inspireret af aspect-oriented programming og er ideelle til cross-cutting concerns som logging, response transformation, caching og timing.
()
{
(: , : ): <> {
.();
now = .();
next.().(
( .()),
);
}
}
En interceptor implementerer intercept(). Kode før next.handle() køres før handleren; next.handle() returnerer en RxJS Observable af response, og operatorer som tap/map lader dig handle response efter handleren er færdig.
@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 }
);
}
}
Med map kan en interceptor omforme hver response — f.eks. ved at pakke alle responses ind i en standard envelope, et meget almindeligt pattern for konsistente 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
Det definerende feature: interceptors kan køre logik efter handleren og transformere response — som middleware og guards ikke kan gøre på en ren måde.
Interceptors er en kraftfuld NestJS-feature til at håndtere cross-cutting concerns elegantly, og deres unikke evne — at køre logik både før og efter handleren, og transformere response — gør dem til det rigtige værktøj til behov som middleware og guards ikke kan håndtere.
Det er vigtigt at forstå dem, fordi mange almindelige krav mapper naturligt til interceptors: konsistent response-formatering (indpakning af alle responses i en standard { success, data } envelope), logging/timing (måling af handler-varighed), caching (returnering af cachede responses), timeouts, error transformation og serialization (udelukkelse af sensitive felter).
Kendskab til strukturen (den next.handle() Observable, med tap/map/catchError til at handle før/efter), de almindelige use cases, og især hvordan interceptors adskiller sig fra middleware og guards (evnen til at pakke ind og transformere response) er en vigtig del af NestJS architectural competence.
Interceptors holder cross-cutting logik DRY og centraliseret i stedet for duplikeret på tværs af handlers, hvilket gør dem til et hyppigt brugt og vigtigt værktøj til at bygge rene, vedligeholdelige NestJS-applikationer.