Hvordan fungerer en requests livscyklus i Laravel?

Question

IT Interview Practice · Accepted Answer

Hver Laravel-request kommer ind gennem en enkelt front controller, `public/index.php`, drives af **HTTP-kernen** gennem en **middleware**-stak og **routeren** til en **controller**, og returnerer et `Response` — hvorefter **terminable** middleware kører.

## Faserne

```
public/index.php  ── autoload + bootstrap af appen
   ▼
HTTP Kernel::handle($request)
   ▼
Bootstrappers  ── env, config, providers (register + boot)
   ▼
Global middleware  ── (TrustProxies, HandleCors, ...)
   ▼
Router dispatch  ── match route
   ▼
Route / group middleware  ── (auth, throttle, verified, ...)
   ▼
Controller (or closure)  ── din logik → returnerer et Response
   ▼
Response ──▶ client
   ▼
Kernel::terminate  ── terminable middleware (f.eks. session-gem, logging)
```

1. **Front controller** — `index.php` indlæser Composer autoload og bootstrapper applikationscontaineren.
2. **Kernel::handle** — HTTP-kernen modtager `Request` og kører **bootstrapperne**: indlæser env + config, registrerer og **booter** service providers (det er her frameworket og dine bindings kobles op).
3. **Global middleware** — kører for hver request (CORS, vedligeholdelsestilstand, trimning af strenge, proxy-tillid).
4. **Routing** — routeren matcher URI + verbet til en route.
5. **Route/group middleware** — middleware tilknyttet routen eller dens gruppe (`auth`, `throttle`, `verified`) kører før controlleren; hver kan kortslutte.
6. **Controller** — din action (eller route-closure) kører, bruger modeller/services og returnerer et `Response` (view, JSON, redirect). Middlewarens "efter"-logik kører, mens svaret bobler tilbage ud.
7. **terminate** — efter svaret er sendt, kører `Kernel::terminate` terminable middleware til udskudt arbejde.

```php
// app/Http/Middleware/Timing.php  → 3/5. middleware
public function handle($request, Closure $next)
{
    $request->attributes->set('started', microtime(true));
    $response = $next($request);          // send til næste lag / controller
    $response->headers->set('X-Time', '...');  // "efter"-logik
    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));
}
```

## Hvorfor det betyder noget

Laravels livscyklus er bygget op omkring **service containeren** og **middleware-pipelinen**, så det at kende rækkefølgen — bootstrap/providers, så global middleware, så routing, så route-middleware, så controller, så `terminate` — fortæller dig præcist, hvor auth, rate limiting, CORS og oprydning hører hjemme. Den forklarer, hvorfor en service skal bindes i en provider, før den injiceres, hvorfor `throttle` afviser en request, før din controller kører, og hvordan man udskyder langsomt arbejde til terminable middleware, så brugeren ikke holdes ventende.

Faserne

Hvorfor det betyder noget

Relaterede spørgsmål