Kas yra middleware programoje NestJS ir kuo jis skiriasi nuo guards/interceptors?

Question

Accepted Answer

**Middleware** yra funkcija, kuri veikia **prieš route handler**, turėdama prieigą prie request ir response objektų — tai ta pati koncepcija kaip Express middleware. NestJS taip pat turi guards, interceptors, pipes ir filters, kurių kiekvienas veikia tam tikrame request lifecycle taške su skirtingu tikslu. Žinoti, kurį naudoti, yra svarbu.

## Middleware — veikia pirmas, turi 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 veikia pirmiausia, prieš guards/interceptors/pipes, ir dirba su raw `req`/`res` — gerai tinka žurnalams, request modifikavimui, CORS ir Express suderintiems dalykams.

## Visas request lifecycle eilės sąrašas

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

## Kam kiekvienas skirtas (rinkdamiesi tinkamą įrankį)

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

Pagrindiniai skirtumai: middleware yra bendras Express stiliaus pre-processing; **guards** konkrečiai tvarko autorizaciją (švarus, dedikuotas vietas autentifikacijai, priešingai nei susmulkinti ją middleware); **interceptors** apipavidalina handler, kad transformuotų responses arba pridėtų cross-cutting behavior; **pipes** patikrina input; **filters** tvarko klaidas.

## Kada naudoti middleware vs guards vs 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
```

## Kodėl tai svarbu

Supratimas middleware ir jo skirtumų nuo guards, interceptors, pipes ir filters yra esencialus teisingam NestJS aplikacijų struktūrizavimui — kiekvienas turi specifinį vaidmenį ir veikia specifiniame request lifecycle taške, o tinkamo naudojimas veda prie švaraus, idiomatinio kodo.

Middleware tvarko bendrą Express stiliaus pre-processing su raw req/res.

Krucialūs skirtumai yra, kad **guards** yra dedikuota, tinkama vieta autorizacijai (auth/roles) — daug švariau nei middleware tam tikslui — ir **interceptors** apipavidalina handler, kad transformuotų responses ir pridėtų cross-cutting concerns (logging, caching, timing), kuriuos middleware sunkiai gali padaryti (nes jis veikia prieš handler ir natūraliai nemato response).

Žinoti visą lifecycle eilės sąrašą (middleware → guards → interceptors → pipes → handler → interceptors → filters) ir kuris įrankis tinka kiekvienai priežiūrai (auth → guard, response transformation → interceptor, validation → pipe, errors → filter) yra NestJS kompetencijos žymė ir išvengus bendra klaida — neteisingai naudoti middleware visam.