Django-இல் request lifecycle எப்படி வேலை செய்கிறது?

Question

IT Interview Practice · Accepted Answer

Django-இல், ஒரு request **WSGI/ASGI handler** மூலம் கையாளப்படுகிறது, **middleware** அடுக்கால் மூடப்படுகிறது, **URL resolver** மூலம் ஒரு **view**-க்கு வழிநடத்தப்படுகிறது, மற்றும் அதே middleware வழியாக தலைகீழ் வரிசையில் மீண்டும் வெளியேறும் ஒரு `HttpResponse` ஆக மாற்றப்படுகிறது.

## நிலைகள்

```
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-இன் code *`get_response()`-க்கு முன்* மேலிருந்து கீழாக இயங்குகிறது (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). அவற்றில் எதுவும் முன்கூட்டியே நிறுத்தி ஒரு response-ஐ திருப்பித்தரலாம்.
3. **URL resolution** — `ROOT_URLCONF` pattern-கள் ஒரு view-ஐ தேர்ந்தெடுத்து kwargs-ஐ பிடிக்க path-உடன் பொருத்தப்படுகின்றன.
4. **`process_view`** — view அழைக்கப்படுவதற்கு சற்று முன் இயங்கும் ஒரு middleware hook.
5. **View** — உங்கள் function- அல்லது class-based view இயங்குகிறது, பொதுவாக model-களை query செய்து ஒரு template-ஐ render செய்கிறது, மற்றும் ஒரு `HttpResponse`-ஐ திருப்பித்தருகிறது. விதிவிலக்குகள் `process_exception`-ஐ தூண்டுகின்றன.
6. **Middleware, response கட்டம்** — code *`get_response()`-க்குப் பின்* கீழிருந்து மேலாக இயங்குகிறது, வெளியேறும் response-ஐ (headers, compression) மாற்ற middleware-ஐ அனுமதிக்கிறது.
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)  # அடுத்த அடுக்கை / 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-ஐ மையமாகக் கொண்டது, எனவே பெரும்பாலான குறுக்குவெட்டு நடத்தை — auth, sessions, CSRF, security headers, caching — வரிசைப்படுத்தப்பட்ட middleware ஆக செயல்படுத்தப்படுகிறது. request-கட்ட code மேலிருந்து கீழாகவும், response-கட்ட code கீழிருந்து மேலாகவும் இயங்குகிறது (மற்றும் `MIDDLEWARE`-இல் வரிசை முக்கியம்) என்பதைப் புரிந்துகொள்வது உங்கள் சொந்த middleware-ஐ சரியாக வைக்க, உங்கள் view-க்கு முன் ஒரு `403`/redirect ஏன் நிகழ்கிறது என்பதை debug செய்ய, மற்றும் ஒவ்வொரு view-ஐயும் தொடாமல் logic-ஐ எங்கே இணைப்பது என்பதை அறிய அவசியம்.

நிலைகள்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்