Django میں request lifecycle کیسے کام کرتا ہے؟

Question

IT Interview Practice · Accepted Answer

Django میں، ایک request کو **WSGI/ASGI handler** ہینڈل کرتا ہے، **middleware** کے ایک اسٹیک سے لپیٹا جاتا ہے، **URL resolver** کے ذریعے ایک **view** تک روٹ کیا جاتا ہے، اور ایک `HttpResponse` میں تبدیل کیا جاتا ہے جو اسی middleware سے الٹی ترتیب میں واپس باہر بہتا ہے۔

## مراحل

```
Web server ──▶ WSGI/ASGI handler  (HttpRequest بناتا ہے)
   ▼
Middleware — request مرحلہ        (اوپر → نیچے: get_response سے پہلے __call__)
   ▼
URL resolver (urls.py)  ── path میچ کریں → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (function / class-based)  ── آپ کی logic، HttpResponse لوٹاتا ہے
   ▼
Middleware — response مرحلہ        (نیچے → اوپر: get_response کے بعد)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (sync) یا ASGI (async) handler environ/scope سے ایک `HttpRequest` بناتا ہے۔
2. **Middleware, request مرحلہ** — ہر middleware کا `get_response()` سے *پہلے* والا code اوپر سے نیچے چلتا ہے (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …)۔ ان میں سے کوئی بھی short-circuit کر کے جلدی ایک response لوٹا سکتا ہے۔
3. **URL resolution** — ایک view منتخب کرنے اور kwargs پکڑنے کے لیے `ROOT_URLCONF` patterns کو path سے میچ کیا جاتا ہے۔
4. **`process_view`** — ایک middleware hook جو view کو کال کیے جانے سے بالکل پہلے چلتا ہے۔
5. **View** — آپ کا function- یا class-based view چلتا ہے، عموماً models کو query کرتا اور ایک template render کرتا ہے، اور ایک `HttpResponse` لوٹاتا ہے۔ استثناءات `process_exception` کو ٹرگر کرتی ہیں۔
6. **Middleware, response مرحلہ** — `get_response()` کے *بعد* والا code نیچے سے اوپر چلتا ہے، جو middleware کو باہر جانے والی response (headers, compression) میں ترمیم کرنے دیتا ہے۔
7. `HttpResponse` کو server اور client کو واپس stream کیا جاتا ہے۔

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

def __call__(self, request):          # 2. request مرحلہ (پہلے)
        request.started = time.monotonic()
        response = self.get_response(request)  # اگلی layer / view کو کال کرتا ہے
        response["X-Time"] = "..."         # 6. response مرحلہ (بعد)
        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)})
```

## یہ کیوں اہم ہے

Django کا request/response سائیکل middleware پر مرکوز ہے، اس لیے زیادہ تر cross-cutting رویہ — auth, sessions, CSRF, security headers, caching — ترتیب شدہ middleware کے طور پر نافذ ہوتا ہے۔ یہ سمجھنا کہ request-مرحلہ code اوپر سے نیچے چلتا ہے اور response-مرحلہ code نیچے سے اوپر چلتا ہے (اور یہ کہ `MIDDLEWARE` میں ترتیب اہم ہے) آپ کے اپنے middleware کو درست جگہ رکھنے، یہ debug کرنے کہ آپ کے view سے پہلے کوئی `403`/redirect کیوں ہوتا ہے، اور یہ جاننے کے لیے کہ ہر view کو چھوئے بغیر logic کہاں hook کریں، ضروری ہے۔

مراحل

یہ کیوں اہم ہے

متعلقہ سوالات