Jak działa cykl życia żądania w Django?

Question

IT Interview Practice · Accepted Answer

W Django żądanie jest obsługiwane przez **WSGI/ASGI handler**, opakowane przez stos **middleware**, kierowane przez **URL resolver** do **widoku (view)** i zamieniane w `HttpResponse`, który wraca na zewnątrz przez ten sam middleware w odwrotnej kolejności.

## Etapy

```
Web server ──▶ WSGI/ASGI handler  (tworzy HttpRequest)
   ▼
Middleware — faza request          (góra → dół: __call__ przed get_response)
   ▼
URL resolver (urls.py)  ── dopasuj path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── Twoja logika, zwraca HttpResponse
   ▼
Middleware — faza response         (dół → góra: po get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — handler WSGI (synchroniczny) lub ASGI (asynchroniczny) buduje `HttpRequest` z environ/scope.
2. **Middleware, faza request** — kod każdego middleware *przed* `get_response()` uruchamia się od góry do dołu (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Każdy z nich może przerwać łańcuch i wcześniej zwrócić odpowiedź.
3. **Rozwiązywanie URL** — wzorce `ROOT_URLCONF` są dopasowywane do ścieżki, aby wybrać widok i przechwycić kwargs.
4. **`process_view`** — hook middleware uruchamiany tuż przed wywołaniem widoku.
5. **View** — Twój widok funkcyjny lub klasowy uruchamia się, zwykle odpytuje modele i renderuje szablon, a następnie zwraca `HttpResponse`. Wyjątki wyzwalają `process_exception`.
6. **Middleware, faza response** — kod *po* `get_response()` uruchamia się od dołu do góry, pozwalając middleware modyfikować wychodzącą odpowiedź (nagłówki, kompresja).
7. `HttpResponse` jest strumieniowany z powrotem do serwera i klienta.

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

def __call__(self, request):          # 2. faza request (przed)
        request.started = time.monotonic()
        response = self.get_response(request)  # wywołuje następną warstwę / view
        response["X-Time"] = "..."         # 6. faza response (po)
        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)})
```

## Dlaczego to ważne

Cykl żądanie/odpowiedź w Django jest skoncentrowany na middleware, więc większość zachowań przekrojowych — auth, sesje, CSRF, nagłówki bezpieczeństwa, cache'owanie — jest zaimplementowana jako uporządkowany middleware. Zrozumienie, że kod fazy request działa z góry na dół, a kod fazy response z dołu do góry (i że kolejność w `MIDDLEWARE` ma znaczenie), jest kluczowe, aby poprawnie umieścić własny middleware, zdebugować, dlaczego `403`/przekierowanie pojawia się przed Twoim widokiem, i wiedzieć, gdzie podpiąć logikę bez dotykania każdego widoku.

Etapy

Dlaczego to ważne

Powiązane pytania