Come funziona il request lifecycle in Laravel?

Question

IT Interview Practice · Accepted Answer

Ogni request Laravel entra attraverso un unico front controller, `public/index.php`, viene guidata dall'**HTTP Kernel** attraverso uno stack di **middleware** e il **router** fino a un **controller**, e restituisce un `Response` — dopodiché viene eseguito il middleware **terminable**.

## Le fasi

```
public/index.php  ── autoload + bootstrap dell'app
   ▼
HTTP Kernel::handle($request)
   ▼
Bootstrappers  ── env, config, providers (register + boot)
   ▼
Global middleware  ── (TrustProxies, HandleCors, ...)
   ▼
Router dispatch  ── abbina route
   ▼
Route / group middleware  ── (auth, throttle, verified, ...)
   ▼
Controller (o closure)  ── la tua logica → restituisce un Response
   ▼
Response ──▶ client
   ▼
Kernel::terminate  ── terminable middleware (es. salvataggio session, logging)
```

1. **Front controller** — `index.php` carica l'autoload di Composer e fa il bootstrap del container dell'applicazione.
2. **Kernel::handle** — l'HTTP Kernel riceve il `Request` ed esegue i **bootstrapper**: carica env + config, registra e fa il **boot** dei service provider (è qui che il framework e i tuoi binding vengono collegati).
3. **Global middleware** — viene eseguito per ogni request (CORS, modalità di manutenzione, trimming delle stringhe, fiducia nel proxy).
4. **Routing** — il router abbina URI + verb a una route.
5. **Route/group middleware** — il middleware assegnato alla route o al suo gruppo (`auth`, `throttle`, `verified`) viene eseguito prima del controller; ognuno può interrompere il flusso.
6. **Controller** — la tua action (o route closure) viene eseguita, usa model/service, e restituisce un `Response` (view, JSON, redirect). La logica "dopo" del middleware viene eseguita mentre la response risale verso l'esterno.
7. **terminate** — dopo che la response è stata inviata, `Kernel::terminate` esegue il terminable middleware per il lavoro differito.

```php
// app/Http/Middleware/Timing.php  → 3/5. middleware
public function handle($request, Closure $next)
{
    $request->attributes->set('started', microtime(true));
    $response = $next($request);          // passa al layer successivo / controller
    $response->headers->set('X-Time', '...');  // logica "dopo"
    return $response;
}

// routes/web.php  → 4. routing (+ middleware)
Route::get('/items/{id}', [ItemController::class, 'show'])->middleware('auth');

// app/Http/Controllers/ItemController.php  → 6. controller
public function show(int $id)
{
    return response()->json(Item::findOrFail($id));
}
```

## Perché è importante

Il lifecycle di Laravel è costruito attorno al **service container** e alla **middleware pipeline**, quindi conoscere l'ordine — bootstrap/provider, poi global middleware, poi routing, poi route middleware, poi controller, poi `terminate` — ti dice esattamente dove appartengono auth, rate limiting, CORS e cleanup. Spiega perché un service deve essere associato in un provider prima di essere iniettato, perché `throttle` rifiuta una request prima che giri il tuo controller, e come differire il lavoro lento al terminable middleware in modo che l'utente non venga fatto aspettare.

Le fasi

Perché è importante

Domande correlate