Kako funkcionira životni ciklus zahtjeva u Djangu?

Question

IT Interview Practice · Accepted Answer

U Djangu zahtjev obrađuje **WSGI/ASGI handler**, omata ga stog **middlewarea**, **URL resolver** ga usmjerava na **view**, a pretvara se u `HttpResponse` koji teče natrag van kroz isti middleware obrnutim redoslijedom.

## Faze

```
Web server ──▶ WSGI/ASGI handler  (kreira HttpRequest)
   ▼
Middleware — request faza          (vrh → dno: __call__ prije get_response)
   ▼
URL resolver (urls.py)  ── uskladi path → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (funkcijski / klasni)  ── tvoja logika, vraća HttpResponse
   ▼
Middleware — response faza          (dno → vrh: nakon get_response)
   ▼
HttpResponse ──▶ klijent
```

1. **Handler** — WSGI (sinkroni) ili ASGI (asinkroni) handler gradi `HttpRequest` iz environa/scopea.
2. **Middleware, request faza** — kod svakog middlewarea *prije* `get_response()` izvršava se od vrha prema dnu (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Bilo koji od njih može presjeći tok i rano vratiti response.
3. **URL resolution** — obrasci iz `ROOT_URLCONF` uspoređuju se s pathom kako bi se odabrao view i uhvatili kwargs.
4. **`process_view`** — middleware hook koji se izvršava neposredno prije poziva viewa.
5. **View** — tvoj funkcijski ili klasni view se izvršava, tipično upitujući modele i renderirajući template, te vraća `HttpResponse`. Iznimke aktiviraju `process_exception`.
6. **Middleware, response faza** — kod *nakon* `get_response()` izvršava se od dna prema vrhu, dopuštajući middlewareu da izmijeni odlazni response (headeri, kompresija).
7. `HttpResponse` se streama natrag serveru i klijentu.

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

def __call__(self, request):          # 2. request faza (prije)
        request.started = time.monotonic()
        response = self.get_response(request)  # poziva sljedeći sloj / view
        response["X-Time"] = "..."         # 6. response faza (nakon)
        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)})
```

## Zašto je to važno

Djangov request/response ciklus usredotočen je na middleware, pa je većina presijecajućeg ponašanja — auth, sessioni, CSRF, security headeri, caching — implementirana kao uređeni middleware. Razumijevanje da se kod request faze izvršava od vrha prema dnu, a kod response faze od dna prema vrhu (i da je redoslijed u `MIDDLEWARE` bitan) ključno je za ispravno postavljanje vlastitog middlewarea, otkrivanje zašto se `403`/redirect dogodi prije tvog viewa te za znanje gdje ukopčati logiku bez diranja svakog viewa.

Faze

Zašto je to važno

Povezana pitanja