Bagaimana cara kerja request lifecycle di Django?

Question

IT Interview Practice · Accepted Answer

Di Django, sebuah request ditangani oleh **WSGI/ASGI handler**, dibungkus oleh sebuah tumpukan **middleware**, dirutekan oleh **URL resolver** ke sebuah **view**, dan diubah menjadi sebuah `HttpResponse` yang mengalir kembali keluar melalui middleware yang sama secara terbalik.

## Tahapannya

```
Web server ──▶ WSGI/ASGI handler  (membuat HttpRequest)
   ▼
Middleware — fase request          (atas → bawah: __call__ sebelum get_response)
   ▼
URL resolver (urls.py)  ── cocokkan path → view + kwargs
   ▼
Middleware — hook process_view
   ▼
View (function / class-based)  ── logika Anda, mengembalikan HttpResponse
   ▼
Middleware — fase response         (bawah → atas: setelah get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — handler WSGI (sync) atau ASGI (async) membangun sebuah `HttpRequest` dari environ/scope.
2. **Middleware, fase request** — kode setiap middleware *sebelum* `get_response()` berjalan dari atas ke bawah (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Salah satu darinya bisa memutus jalur dan mengembalikan response lebih awal.
3. **Resolusi URL** — pola-pola `ROOT_URLCONF` dicocokkan dengan path untuk memilih sebuah view dan menangkap kwargs.
4. **`process_view`** — sebuah hook middleware yang berjalan tepat sebelum view dipanggil.
5. **View** — view berbasis fungsi atau kelas Anda berjalan, biasanya melakukan query model dan me-render sebuah template, lalu mengembalikan sebuah `HttpResponse`. Exception memicu `process_exception`.
6. **Middleware, fase response** — kode *setelah* `get_response()` berjalan dari bawah ke atas, membiarkan middleware memodifikasi response yang keluar (header, kompresi).
7. `HttpResponse` di-stream kembali ke server dan client.

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

def __call__(self, request):          # 2. fase request (sebelum)
        request.started = time.monotonic()
        response = self.get_response(request)  # memanggil lapisan berikutnya / view
        response["X-Time"] = "..."         # 6. fase response (sesudah)
        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)})
```

## Mengapa ini penting

Siklus request/response Django berpusat pada middleware, jadi sebagian besar perilaku lintas-potong — auth, session, CSRF, security header, caching — diimplementasikan sebagai middleware yang terurut. Memahami bahwa kode fase-request berjalan dari atas ke bawah dan kode fase-response berjalan dari bawah ke atas (dan bahwa urutan di `MIDDLEWARE` itu penting) sangat esensial untuk menempatkan middleware Anda sendiri dengan benar, men-debug kenapa sebuah `403`/redirect terjadi sebelum view Anda, dan mengetahui di mana harus menyisipkan logika tanpa menyentuh setiap view.

Tahapannya

Mengapa ini penting

Pertanyaan terkait