NestJS માં વિનંતી જીવનચક્ર ક્રમ શું છે?

Question

Accepted Answer

**વિનંતી જીવનચક્ર** એ NestJS માં વિનંતી પસાર થાય છે તે ઘટકોનો ચોક્કસ ક્રમ છે — middleware, guards, interceptors, pipes, handler, પછી ફરીથી interceptors, અને ભૂલો પર exception filters. ચોક્કસ ક્રમ જાણવો અત્યંત મહત્વપૂર્ણ છે *ક્યારે* દરેક તર્કનો ભાગ ચલે છે તે સમજવા માટે.

## The full order

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

## Why the order matters (practical consequences)

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

## Within each category, scope ordering applies

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

## A concrete example

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

## આ શા માટે મહત્વપૂર્ણ છે

વિનંતી જીવનચક્ર ક્રમને સમજવું NestJS એપ્લિકેશનોને સાચી રીતે બનાવવા માટે મૂળભૂત છે — તે ચોક્કસ *ક્યારે* નક્કી કરે છે દરેક ક્રોસ-કટીંગ તર્કનો અમલ થાય છે, જે સીધું ડિઝાઇન નિર્ણય અને ડિબગીંગને અસર કરે છે.

ક્રમમાં વાસ્તવિક, વ્યવહારિક મહત્વ છે: **guards pipes કરતા પહેલે ચલે છે**, તેથી અધિકૃતા ચોક્કસ રીતે ઇનપુટ ચકાસવાથી પહેલે ચકાસવામાં આવે છે (અપ્રમાણિત વિનંતી ચકાસણી પહેલે નકારી કાઢવામાં આવે છે); **pipes handler હોય તેના જ પહેલે ચલે છે**, handler હંમેશા ચકાસાયેલ, રૂપાંતરિત દલીલો મેળવે છે તે ખાતરી આપે છે; **interceptors handler ને લપેટે છે** (પહેલે *અને* પછીથી ચલે છે), જે તેમને અમલ નો સમય કાઢવા અને પ્રતિક્રિયાઓ રૂપાંતર કરવા દે છે તે બરાબર છે; અને **exception filters કોઈપણ તબક્કાથી ભૂલો પકડે છે**, કેન્દ્રિયકૃત ભૂલ નિયંત્રણ સક્ષમ કરે છે.

યો ક્રમ જાણવું — વધુમાં દરેક વર્ગના અંતર્ગત ક્ષેત્ર ક્રમ (વૈશ્વિક → controller → પદ્ધતિ) — તમને તર્ક યોગ્ય ઘટકમાં મૂકવા દે છે, અમલ પ્રવાહ આગોતરી કરવા દે છે, શા માટે કંઈક ચલે છે (અથવા અપેક્ષિત સમયે નહીં ચલે) તે ડિબગ કરવા દે છે, અને વિધેયો સાચી રીતે આર્કિટેક્ચર કરવા દે છે.

તે ફ્રેમવર્કના તમામ વિનંતી-નિયંત્રણ ભાગો (middleware, guards, interceptors, pipes, filters) ને સંગતિપૂર્ણ માનસિક મોડેલમાં બાંધે છે, જે તેને એક મહત્વપૂર્ણ, વારંવાર-પરીક્ષણ કરેલ વિષય બનાવે છે જે NestJS વિનંતીઓ પર પ્રક્રિયા કરે છે તે કેવી રીતે તે વાસ્તવિક સમજણને પ્રતિબિંબિત કરે છે.