Mitä ovat interceptorit?

Question

Accepted Answer

**Interceptorit** käärivät reitinkäsittelijän suorituksen, jolloin voit suorittaa logiikkaa **ennen ja jälkeen** sen — ja muuntaa pyynnön tai vastauksen. Ne ovat inspiroidut aspect-oriented -ohjelmoinnista ja ihanteelliset cross-cutting -huolenaiheille, kuten lokitukselle, vastauksen muuntamiselle, välimuistintamiselle ja ajoitukselle.

## Rakenne: ennen + jälkeen RxJS:n kautta

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

Interceptori toteuttaa `intercept()`. Koodi ennen `next.handle()` -kutsua suoritetaan **ennen** käsittelijää; `next.handle()` palauttaa RxJS `Observable` vastauksen, ja operaattorit kuten `tap`/`map` mahdollistavat toiminnan vastaukselle **jälkeen** käsittelijän valmistumisen.

## Vastauksen muuntaminen (yleinen käyttötapaus)

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

Interceptori voi `map`-operaattorilla muokata jokaista vastausta — esimerkiksi käärimällä kaikki vastaukset vakiokuoreen, hyvin yleinen kuvio yhtenäisille API-vastauksille.

## Muut tehokkaat käyttötavat

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

## Interceptorien käyttöönotto

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

## Interceptorit vs middleware vs vartijat

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

Määrittävä ominaisuus: interceptorit voivat suorittaa logiikkaa **jälkeen** käsittelijää ja **muuntaa vastauksen** — mitä middleware ja vartijat eivät voi tehdä siististi.

## Miksi se on tärkeää

Interceptorit ovat tehokas NestJS-ominaisuus **cross-cutting -huolenaiheita** käsiteltäessä, ja niiden erottava kyky — logiikan suorittaminen sekä ennen *että jälkeen* käsittelijän ja vastauksen muuntaminen — tekee niistä oikean työkalun vaatimuksille, joita middleware ja vartijat eivät pysty käsittelemään.

Ymmärtäminen on tärkeää, koska monet tavalliset vaatimukset kartoittuvat luonnollisesti interceptoreihin: yhtenäinen vastauksen muotoilu (kaikkien vastausten kääriminen vakio-`{ success, data }` -kuoreen), lokitus/ajoitus (käsittelijän keston mittaaminen), välimuistintaminen (välimuistista saadun vastauksen palauttaminen), aikakatkaisut, virheen muuntaminen ja sarjallistaminen (arkaluontoisten kenttien poissulkeminen).

Rakenteen tunteminen (`next.handle()` Observable, jonka kanssa `tap`/`map`/`catchError` toimii ennen/jälkeen), yleiset käyttötapaukset ja erityisesti **kuinka interceptorit eroavat middleware- ja vartija-ratkaisuista** (kyky kääriä ja muuntaa vastaus) on avainosa NestJS-arkkitehtuurista.

Interceptorit pitävät cross-cutting -logiikan DRY-periaatteen mukaisena ja keskitettynä sen sijaan, että se olisi kahdennettua käsittelijöiden yli, jolloin ne muuttuvat usein käytetyksi ja tärkeäksi työkaluksi puhtaiden ja ylläpidettävien NestJS-sovellusten rakentamiseen.