Ποια είναι η σειρά του request lifecycle στο NestJS;

Question

IT Interview Practice · Accepted Answer

Το **Request Lifecycle** είναι η ακριβής ακολουθία στοιχείων που ένα αίτημα διέρχεται μέσω του NestJS — middleware, guards, interceptors, pipes, handler, στη συνέχεια interceptors πάλι, και exception filters σε περίπτωση σφαλμάτων. Η γνώση της ακριβούς σειράς είναι κρίσιμη για την κατανόηση *πότε* εκτελείται κάθε κομμάτι της λογικής.

## Η πλήρης σειρά

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

## Ένα συγκεκριμένο παράδειγμα

```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 — καθορίζει με ακρίβεια *πότε* εκτελείται κάθε κομμάτι της cross-cutting λογικής, το οποίο επηρεάζει άμεσα τις αποφάσεις σχεδιασμού και την αποσφαλμάτωση.

Η σειρά έχει πραγματική, πρακτική σημασία: **τα guards τρέχουν πριν τα pipes**, έτσι η εξουσιοδότηση ελέγχεται σωστά πριν ασχοληθούμε με την επικύρωση της εισόδου (ένα ανεξουσίοδοτο αίτημα απορρίπτεται πριν την επικύρωση); **τα pipes τρέχουν ακριβώς πριν το handler**, εγγυώντας ότι το handler λαμβάνει πάντα επικυρωμένα, μετασχηματισμένα ορίσματα; **τα interceptors περιτυλίγουν το handler** (εκτελούνται πριν *και* μετά), το οποίο είναι ακριβώς αυτό που τους επιτρέπει να χρονίζουν την εκτέλεση και να μετασχηματίζουν τις απαντήσεις; και **τα exception filters συλλαμβάνουν σφάλματα από οποιοδήποτε στάδιο**, ενεργοποιώντας κεντρική διαχείριση σφαλμάτων.

Η γνώση αυτής της σειράς — συν τα scope ordering εντός κατηγοριών (global → controller → method) — σας επιτρέπει να τοποθετήσετε τη λογική στο σωστό στοιχείο, να προβλέψετε τη ροή εκτέλεσης, να αποσφαλματώσετε γιατί κάτι τρέχει (ή όχι) όταν αναμένεται, και να αρχιτεκτονήσετε δυνατότητες σωστά.

Συνδέει όλα τα κομμάτια διαχείρισης αιτημάτων του framework (middleware, guards, interceptors, pipes, filters) σε ένα συνεκτικό νοητικό μοντέλο, κάνοντάς το ένα σημαντικό, συχνά δοκιμασμένο θέμα που αντικατοπτρίζει γνήσια κατανόηση του τρόπου που το NestJS επεξεργάζεται τα αιτήματα.

Η πλήρης σειρά

Γιατί η σειρά είναι σημαντική (πρακτικές συνέπειες)

Εντός κάθε κατηγορίας, ισχύει scope ordering

Ένα συγκεκριμένο παράδειγμα

Γιατί είναι σημαντικό

Σχετικές ερωτήσεις