Come funziona il request lifecycle in Django?

Question

IT Interview Practice · Accepted Answer

In Django, una request viene gestita dal **WSGI/ASGI handler**, avvolta da uno stack di **middleware**, instradata dall'**URL resolver** verso una **view**, e trasformata in un `HttpResponse` che rifluisce verso l'esterno attraverso gli stessi middleware in ordine inverso.

## Le fasi

```
Web server ──▶ WSGI/ASGI handler  (crea HttpRequest)
   ▼
Middleware — fase request          (alto → basso: __call__ prima di get_response)
   ▼
URL resolver (urls.py)  ── abbina path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── la tua logica, restituisce HttpResponse
   ▼
Middleware — fase response         (basso → alto: dopo get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — l'handler WSGI (sync) o ASGI (async) costruisce un `HttpRequest` a partire da environ/scope.
2. **Middleware, fase request** — il codice di ciascun middleware *prima* di `get_response()` viene eseguito dall'alto verso il basso (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Ognuno di essi può interrompere il flusso e restituire una response in anticipo.
3. **Risoluzione URL** — i pattern di `ROOT_URLCONF` vengono abbinati al path per selezionare una view e catturare i kwargs.
4. **`process_view`** — un hook di middleware che viene eseguito subito prima che la view venga chiamata.
5. **View** — la tua view basata su funzione o classe viene eseguita, tipicamente interrogando i model e renderizzando un template, e restituisce un `HttpResponse`. Le eccezioni attivano `process_exception`.
6. **Middleware, fase response** — il codice *dopo* `get_response()` viene eseguito dal basso verso l'alto, permettendo al middleware di modificare la response in uscita (header, compressione).
7. L'`HttpResponse` viene restituito in streaming al server e al client.

```python
# middleware.py
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

def __call__(self, request):          # 2. fase request (prima)
        request.started = time.monotonic()
        response = self.get_response(request)  # chiama il layer successivo / view
        response["X-Time"] = "..."         # 6. fase response (dopo)
        return response

# urls.py  → 3. routing
urlpatterns = [path("items/<int:pk>/", views.item_detail)]

# views.py → 5. view
def item_detail(request, pk):
    return render(request, "item.html", {"item": Item.objects.get(pk=pk)})
```

## Perché è importante

Il ciclo request/response di Django è incentrato sui middleware, quindi la maggior parte dei comportamenti trasversali — auth, session, CSRF, security header, caching — è implementata come middleware ordinati. Capire che il codice della fase-request viene eseguito dall'alto verso il basso e quello della fase-response dal basso verso l'alto (e che l'ordine in `MIDDLEWARE` conta) è essenziale per posizionare correttamente i tuoi middleware, per fare il debug del perché un `403`/redirect avviene prima della tua view, e per sapere dove agganciare la logica senza toccare ogni singola view.

Le fasi

Perché è importante

Domande correlate