Django માં request lifecycle કેવી રીતે કામ કરે છે?

Question

IT Interview Practice · Accepted Answer

Django માં, એક request ને **WSGI/ASGI handler** દ્વારા હેન્ડલ કરવામાં આવે છે, **middleware** ના stack દ્વારા લપેટવામાં આવે છે, **URL resolver** દ્વારા એક **view** તરફ route કરવામાં આવે છે, અને એક `HttpResponse` માં ફેરવવામાં આવે છે જે એ જ middleware માંથી ઊલટા ક્રમમાં પાછું વહે છે.

## તબક્કાઓ

```
Web server ──▶ WSGI/ASGI handler  (HttpRequest બનાવે છે)
   ▼
Middleware — request phase        (ઉપર → નીચે: get_response પહેલાં __call__)
   ▼
URL resolver (urls.py)  ── path મેચ કરો → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (function / class-based)  ── તમારી logic, HttpResponse પરત કરે છે
   ▼
Middleware — response phase        (નીચે → ઉપર: get_response પછી)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (sync) અથવા ASGI (async) handler environ/scope માંથી એક `HttpRequest` બનાવે છે.
2. **Middleware, request phase** — દરેક middleware નો code `get_response()` *પહેલાં* ઉપરથી-નીચે ચાલે છે (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). તેમાંથી કોઈ પણ short-circuit કરી શકે છે અને વહેલો response પરત કરી શકે છે.
3. **URL resolution** — `ROOT_URLCONF` patterns ને path સાથે મેચ કરીને એક view પસંદ કરવામાં અને kwargs કેપ્ચર કરવામાં આવે છે.
4. **`process_view`** — એક middleware hook જે view ને call કરવામાં આવે તેની બરાબર પહેલાં ચાલે છે.
5. **View** — તમારો function- અથવા class-based view ચાલે છે, સામાન્ય રીતે models ને query કરે છે અને એક template render કરે છે, અને એક `HttpResponse` પરત કરે છે. Exceptions `process_exception` ને trigger કરે છે.
6. **Middleware, response phase** — `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 phase (પહેલાં)
        request.started = time.monotonic()
        response = self.get_response(request)  # આગળના layer / view ને call કરે છે
        response["X-Time"] = "..."         # 6. response phase (પછી)
        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 cycle middleware-કેન્દ્રિત છે, તેથી મોટા ભાગનું cross-cutting behavior — auth, sessions, CSRF, security headers, caching — ordered middleware તરીકે implement થાય છે. એ સમજવું કે request-phase code ઉપરથી-નીચે ચાલે છે અને response-phase code નીચેથી-ઉપર ચાલે છે (અને `MIDDLEWARE` માં ordering મહત્વનું છે) એ તમારા પોતાના middleware ને યોગ્ય રીતે મૂકવા, શા માટે એક `403`/redirect તમારા view પહેલાં થાય છે તે debug કરવા, અને દરેક view ને સ્પર્શ્યા વગર logic ને ક્યાં hook કરવું તે જાણવા માટે આવશ્યક છે.

તબક્કાઓ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો