Si funksionon cikli i jetës së një kërkese në Django?

Question

IT Interview Practice · Accepted Answer

Në Django, një kërkesë trajtohet nga **WSGI/ASGI handler**, mbështillet nga një stak **middleware**, drejtohet nga **URL resolver** te një **view**, dhe kthehet në një `HttpResponse` që rrjedh sërish nga jashtë përmes të njëjtit middleware në rend të kundërt.

## Fazat

```
Web server ──▶ WSGI/ASGI handler  (krijon HttpRequest)
   ▼
Middleware — faza request          (lart → poshtë: __call__ para get_response)
   ▼
URL resolver (urls.py)  ── përputh path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── logjika jote, kthen HttpResponse
   ▼
Middleware — faza response         (poshtë → lart: pas get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — handler-i WSGI (sinkron) ose ASGI (asinkron) ndërton një `HttpRequest` nga environ/scope.
2. **Middleware, faza request** — kodi i çdo middleware *para* `get_response()` ekzekutohet nga lart-poshtë (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Cilido prej tyre mund të ndërpresë zinxhirin dhe të kthejë një përgjigje herët.
3. **Zgjidhja e URL** — pattern-et e `ROOT_URLCONF` përputhen me path-in për të zgjedhur një view dhe për të kapur kwargs.
4. **`process_view`** — një hook middleware që ekzekutohet pak para se view-i të thirret.
5. **View** — view-i yt i bazuar në funksion ose klasë ekzekutohet, zakonisht duke bërë query te modelet dhe duke renderuar një template, dhe kthen një `HttpResponse`. Përjashtimet aktivizojnë `process_exception`.
6. **Middleware, faza response** — kodi *pas* `get_response()` ekzekutohet nga poshtë-lart, duke i lejuar middleware të modifikojë përgjigjen dalëse (headers, kompresim).
7. `HttpResponse` transmetohet sërish te serveri dhe klienti.

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

def __call__(self, request):          # 2. faza request (para)
        request.started = time.monotonic()
        response = self.get_response(request)  # thërret shtresën tjetër / view
        response["X-Time"] = "..."         # 6. faza response (pas)
        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)})
```

## Pse ka rëndësi

Cikli kërkesë/përgjigje i Django është i përqendruar te middleware, ndaj shumica e sjelljes tërthore — auth, sesionet, CSRF, headers të sigurisë, caching — implementohet si middleware i renditur. Të kuptuarit se kodi i fazës request ekzekutohet nga lart-poshtë dhe kodi i fazës response nga poshtë-lart (dhe se renditja në `MIDDLEWARE` ka rëndësi) është thelbësore për të vendosur saktë middleware-in tënd, për të bërë debug pse një `403`/ridrejtim ndodh para view-it tënd, dhe për të ditur ku ta lidhësh logjikën pa prekur çdo view.

Fazat

Pse ka rëndësi

Pyetje të ngjashme