NestJS request lifecycle வரிசை என்ன?

Question

Accepted Answer

**request lifecycle** என்பது NestJS-இல் ஒரு request கடந்து செல்லும் கூறுகளின் துல்லியமான வரிசை — middleware, guards, interceptors, pipes, handler, பின் மீண்டும் interceptors, மற்றும் errors-இல் exception filters. சரியான வரிசையை அறிவது ஒவ்வொரு logic-ம் *எப்போது* இயங்குகிறது என்பதை புரிந்துகொள்ள முக்கியம்.

## முழு வரிசை

```text
Incoming Request
   │
   ▼
1. MIDDLEWARE            (Express-style; raw req/res; runs first)
   │
   ▼
2. GUARDS                (authorization — return true to continue, false/throw to block)
   │
   ▼
3. INTERCEPTORS (pre)    (logic BEFORE the handler — start timing, etc.)
   │
   ▼
4. PIPES                 (validate/transform the handler's arguments — DTO validation)
   │
   ▼
5. ROUTE HANDLER         (your controller method runs)
   │
   ▼
6. INTERCEPTORS (post)   (logic AFTER the handler — transform the response)
   │
   ▼
Response

✗ If an exception is thrown ANYWHERE above →
7. EXCEPTION FILTERS     (catch it and format the error response)
```

## வரிசை ஏன் முக்கியம் (நடைமுறை விளைவுகள்)

```text
• Guards run BEFORE pipes → authorization is checked before input validation
  (no point validating a body for an unauthorized request)
• Pipes run JUST BEFORE the handler → the handler always gets validated/transformed args
• Interceptors straddle the handler → they can measure its duration and transform output
• Filters catch errors from any stage → centralized, consistent error handling
```

## ஒவ்வொரு வகைக்குள், scope ordering பொருந்துகிறது

```text
For each type (guards, interceptors, pipes), they run in this scope order:
  Global → Controller → Method (route)
So a global guard runs before a controller-level guard, before a route-level guard.
```

## ஒரு concrete உதாரணம்

```ts
@Controller("users")
@UseGuards(AuthGuard)                    // 2. checks authorization
@UseInterceptors(LoggingInterceptor)     // 3 (pre) + 6 (post)
export class UsersController {
  @Post()
  create(@Body() dto: CreateUserDto) {    // 4. ValidationPipe validates dto, 5. handler runs
    return this.usersService.create(dto);
  }
}
// Flow: middleware → AuthGuard → LoggingInterceptor(before) → ValidationPipe →
//       create() → LoggingInterceptor(after) → response (or → filter on error)
```

## இது ஏன் முக்கியம்

request lifecycle வரிசையை புரிந்துகொள்வது NestJS applications-ஐ சரியாக கட்டமைக்க அடிப்படை — இது ஒவ்வொரு cross-cutting logic-ம் *எப்போது* execute ஆகிறது என்பதை தீர்மானிக்கிறது, இது design முடிவுகளையும் debugging-ஐயும் நேரடியாக பாதிக்கிறது.

வரிசைக்கு உண்மையான, நடைமுறை முக்கியத்துவம் உள்ளது: **guards pipes-க்கு முன் இயங்குகின்றன**, அதனால் input-ஐ validate செய்ய சிரமப்படுவதற்கு முன் authorization சரியாக சரிபார்க்கப்படுகிறது (ஒரு unauthorized request validation-க்கு முன் நிராகரிக்கப்படுகிறது); **pipes handler-க்கு சற்று முன் இயங்குகின்றன**, handler எப்போதும் validated, transformed arguments-ஐ பெறுவதை உறுதி செய்கிறது; **interceptors handler-ஐ wrap செய்கின்றன** (முன்னும் *பின்னும்* இயங்குதல்), இதுதான் அவை execution-ஐ time செய்து responses-ஐ transform செய்ய அனுமதிக்கிறது; மற்றும் **exception filters எந்த stage-இலிருந்தும் errors-ஐ catch செய்கின்றன**, centralized error handling-ஐ இயலச்செய்கின்றன.

இந்த வரிசையை — மற்றும் within-category scope ordering (global → controller → method)-ஐ — அறிவது logic-ஐ சரியான கூறில் வைக்க, execution flow-ஐ கணிக்க, ஏதாவது எதிர்பார்த்தபடி இயங்குகிறது (அல்லது இயங்கவில்லை) என்பதை debug செய்ய, மற்றும் features-ஐ சரியாக architect செய்ய அனுமதிக்கிறது.

இது framework-இன் அனைத்து request-handling கூறுகளையும் (middleware, guards, interceptors, pipes, filters) ஒரு ஒத்திசைவான மன மாதிரியாக இணைக்கிறது, இதை ஒரு முக்கியமான, அடிக்கடி சோதிக்கப்படும் தலைப்பாக ஆக்குகிறது, இது NestJS requests-ஐ எவ்வாறு செயலாக்குகிறது என்பதன் உண்மையான புரிதலை பிரதிபலிக்கிறது.