Hva er middleware i NestJS og hvordan skiller det seg fra guards/interceptors?

Question

Accepted Answer

**Middleware** er en funksjon som kjøres **før route-handleren**, med tilgang til request- og response-objektene — samme konsept som Express middleware. NestJS har også guards, interceptors, pipes og filters, som hver kjører på et spesifikt punkt i request-livssyklusen med et distinkt formål. Å vite hvilket verktøy som skal brukes, er nøkkelen.

## Middleware — kjører først, har req/res

```ts
@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log(`${req.method} ${req.url}`);   // logging, modifying req
    next();                                      // MUST call next() to continue
  }
}

// register in a module
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(LoggerMiddleware).forRoutes("*");   // apply to routes
  }
}
```

Middleware kjører tidligst, før guards/interceptors/pipes, og arbeider med rå `req`/`res` — bra for logging, request-modifisering, CORS og Express-kompatible forhold.

## Den fullstendige request-livssyklusen

```text
Request →
  1. Middleware     (req/res; runs first, Express-style)
  2. Guards         (return true/false → AUTHORIZE or block the request)
  3. Interceptors   (BEFORE the handler)
  4. Pipes          (validate/transform the handler's arguments)
  5. → Route Handler ←
  6. Interceptors   (AFTER the handler — transform the response)
  7. Exception Filters (if an error was thrown anywhere)
→ Response
```

## Hva hver av dem er FOR (valg av riktig verktøy)

```text
Middleware  → general pre-processing with req/res (logging, CORS, raw request work)
Guards      → AUTHORIZATION — decide if a request may proceed (auth, roles)
              (return true = allow, false/throw = block)
Interceptors→ wrap the handler — transform request/response, add logging/caching/timing
              (can run logic BEFORE and AFTER the handler)
Pipes       → VALIDATE/TRANSFORM the handler's input arguments (DTO validation)
Filters     → catch and format EXCEPTIONS into responses
```

De viktigste forskjellene: middleware er generisk Express-stil pre-prosessering; **guards** håndterer spesifikt autorisasjon (et rent, dedikert sted for auth, i motsetning til å pakke det inn i middleware); **interceptors** omslutter handleren for å transformere responses eller legge til cross-cutting behavior; **pipes** validerer input; **filters** håndterer feil.

## Når middleware skal brukes versus guards versus interceptors

```text
Auth check?           → Guard (dedicated, has execution context, returns boolean)
Logging requests?     → Middleware OR an interceptor (interceptor sees the response too)
Transform responses?  → Interceptor (runs after the handler)
Validate a DTO?       → Pipe
Modify raw req early?  → Middleware
```

## Hvorfor det er viktig

Å forstå middleware og hvordan det skiller seg fra guards, interceptors, pipes og filters er essensielt for å strukturere NestJS-applikasjoner korrekt — hver har en spesifikk rolle og kjører på et spesifikt punkt i request-livssyklusen, og å bruke riktig verktøy fører til rent, idiomatisk kode.

Middleware håndterer generell Express-stil pre-prosessering med rå req/res.

De avgjørende forskjellene er at **guards** er det dedikerte, riktige stedet for autorisasjon (auth/roller) — langt renere enn middleware for det formål — og **interceptors** omslutter handleren for å transformere responses og legge til cross-cutting concerns (logging, caching, timing) som middleware ikke enkelt kan gjøre (siden det kjører før handleren og ikke naturlig ser response).

Å kjenne den fullstendige livssyklusen (middleware → guards → interceptors → pipes → handler → interceptors → filters) og hvilket verktøy som passer for hver concern (auth → guard, response-transformasjon → interceptor, validering → pipe, feil → filter) er et kjennetegn på NestJS-kompetanse og forhindrer den vanlige feilen med å misbruke middleware til alt.

Dette er et hyppig testet, arkitekturelt viktig emne i rammeverket.