Hva er interceptors?

Question

Accepted Answer

**Interceptors** omslutter kjøringen av en route handler, slik at du kan kjøre logikk **før og etter** den — og transformere request eller response. De er inspirert av aspect-oriented programming, ideelle for cross-cutting concerns som logging, response-transformasjon, caching og timing.

## Strukturen: før + etter via RxJS

```ts
@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    console.log("Before handler");          // runs BEFORE the route handler
    const now = Date.now();

return next.handle().pipe(               // next.handle() = invoke the handler
      tap(() => console.log(`After: ${Date.now() - now}ms`)),   // runs AFTER
    );
  }
}
```

En interceptor implementerer `intercept()`. Kode før `next.handle()` kjøres **før** handleren; `next.handle()` returnerer en RxJS `Observable` av responsen, og operatorer som `tap`/`map` lar deg handle responsen **etter** at handleren er ferdig.

## Transformere responsen (en vanlig bruk)

```ts
@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 }
    );
  }
}
```

Ved å bruke `map`, kan en interceptor omforme hver response — f.eks. wrappe alle responses i et standard envelope, et veldig vanlig mønster for konsistente API-responses.

## Andre kraftige bruksområder

```ts
// 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
```

```text
Common interceptor uses:
  ✓ Logging / timing requests (before + after)
  ✓ Transforming responses (consistent envelopes, field exclusion)
  ✓ Caching responses
  ✓ Adding timeouts
  ✓ Mapping/handling errors
```

## Anvende interceptors

```ts
@UseInterceptors(LoggingInterceptor)   // method or controller level
app.useGlobalInterceptors(new TransformInterceptor());   // global
```

## Interceptors vs middleware vs guards

```text
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
```

Den definerende egenskapen: interceptors kan kjøre logikk **etter** handleren og **transformere responsen** — noe som middleware og guards ikke kan gjøre på en ren måte.

## Hvorfor det er viktig

Interceptors er en kraftig NestJS-funksjon for å håndtere **cross-cutting concerns** elegant, og deres særegne evne — å kjøre logikk både før *og etter* handleren, og transformere responsen — gjør dem til riktig verktøy for behov som middleware og guards ikke kan løse.

Det er viktig å forstå dem fordi mange vanlige krav mapper naturlig til interceptors: konsistent response-formatering (wrappe alle responses i et standard `{ success, data }` envelope), logging/timing (måle handler-varighet), caching (returnere cachede responses), timeouts, error-transformasjon og serialisering (ekskludere sensitive felter).

Å kjenne strukturen (the `next.handle()` Observable, med `tap`/`map`/`catchError` for å handle før/etter), de vanlige use cases-ene, og spesielt **hvordan interceptors skiller seg fra middleware og guards** (evnen til å wrappe og transformere responsen) er en viktig del av NestJS-arkitektur-kompetanse.

Interceptors holder cross-cutting logikk DRY og sentralisert i stedet for duplisert på tvers av handlers, noe som gjør dem til et hyppig brukt, viktig verktøy for å bygge rene, vedlikeholdbare NestJS-applikasjoner.