როგორ მუშაობს მოთხოვნის სასიცოცხლო ციკლი Django-ში?

Question

IT Interview Practice · Accepted Answer

Django-ში მოთხოვნას ამუშავებს **WSGI/ASGI handler**, ახვევს **middleware**-ების სტეკი, **URL resolver** მარშრუტიზებს მას **view**-ზე, და გარდაიქმნება `HttpResponse`-ად, რომელიც იმავე middleware-ში უკუღმა მიედინება უკან გარეთ.

## ეტაპები

```
Web server ──▶ WSGI/ASGI handler  (ქმნის HttpRequest-ს)
   ▼
Middleware — request ფაზა          (ზემოდან → ქვემოთ: __call__ get_response-ამდე)
   ▼
URL resolver (urls.py)  ── ამთხვევს path → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (function / class-based)  ── თქვენი ლოგიკა, აბრუნებს HttpResponse-ს
   ▼
Middleware — response ფაზა         (ქვემოდან → ზემოთ: get_response-ის შემდეგ)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI (სინქრონული) ან ASGI (ასინქრონული) handler აგებს `HttpRequest`-ს environ/scope-იდან.
2. **Middleware, request ფაზა** — თითოეული middleware-ის `get_response()`-ის *წინა* კოდი მუშაობს ზემოდან ქვემოთ (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). ნებისმიერ მათგანს შეუძლია გზა შეაჩეროს და response ადრე დააბრუნოს.
3. **URL გადაწყვეტა** — `ROOT_URLCONF`-ის შაბლონები ემთხვევა path-ს, რათა შეირჩეს view და დაიჭიროს kwargs.
4. **`process_view`** — middleware-ის hook, რომელიც სრულდება view-ის გამოძახებამდე ცოტა ხნით ადრე.
5. **View** — თქვენი ფუნქცია- ან კლას-დაფუძნებული view სრულდება, ჩვეულებრივ ითხოვს მოდელებს და არენდერებს template-ს, და აბრუნებს `HttpResponse`-ს. გამონაკლისები იწვევენ `process_exception`-ს.
6. **Middleware, response ფაზა** — `get_response()`-ის *შემდეგ* კოდი მუშაობს ქვემოდან ზემოთ, რაც middleware-ს აძლევს საშუალებას შეცვალოს გამავალი response (header-ები, შეკუმშვა).
7. `HttpResponse` სტრიმად ბრუნდება სერვერსა და client-ს.

```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, session, CSRF, security header-ები, caching — დანერგილია დალაგებული middleware-ის სახით. იმის გაგება, რომ request-ფაზის კოდი მუშაობს ზემოდან ქვემოთ და response-ფაზის კოდი ქვემოდან ზემოთ (და რომ `MIDDLEWARE`-ში თანმიმდევრობას აქვს მნიშვნელობა), აუცილებელია იმისთვის, რომ საკუთარი middleware სწორად განათავსოთ, გამართოთ, თუ რატომ ხდება `403`/გადამისამართება თქვენს view-მდე, და იცოდეთ, სად ჩააბათ ლოგიკა ისე, რომ ყველა view-ს არ შეეხოთ.

ეტაპები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები