რა არის middleware Django-ში?

Question

Accepted Answer

**Middleware** არის hooks-ების ჩარჩო, რომელიც ამუშავებს **თითოეულ request-ს და response-ს** გლობალურად, მდგომარე ვებ-სერვერსა და თქვენი views-ის შორის. თითოეული middleware შეუძლია inspect/modify გააკეთოს requests-ები შემომავალ გზაზე და responses-ები გამომავალ გზაზე — იდეალური cross-cutting concerns-ებისთვის, როგორიცაა authentication, security headers, sessions, და logging.

## Request/response flow middleware-ის მეშვეობით

```text
Request  → MW1 → MW2 → MW3 → VIEW
Response ← MW1 ← MW2 ← MW3 ← VIEW

Middleware wraps the view like layers of an onion:
  - on the way IN (request): top-to-bottom
  - on the way OUT (response): bottom-to-top (reverse order)
```

## Django-ის built-in middleware (settings.py-ში)

```python
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",          # security headers (HSTS, etc.)
    "django.contrib.sessions.middleware.SessionMiddleware",   # enables request.session
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",              # CSRF protection
    "django.contrib.auth.middleware.AuthenticationMiddleware",# enables request.user
    "django.middleware.clickjacking.XFrameOptionsMiddleware", # clickjacking protection
]
# ORDER MATTERS — e.g. SessionMiddleware must come before AuthenticationMiddleware
```

Django-ის დიდი ნაწილი functionality middleware-ია: sessions (`request.session`), authentication (`request.user`), CSRF protection, და security headers ყველა built-in middleware-დან მოდის. **順序 მნიშვნელოვანია** — ზოგიერთი middleware დამოკიდებულია სხვა middleware-ის აქ ჯერ გაშვებაზე.

## Custom middleware-ის დაწერა

```python
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response          # the next middleware/view

def __call__(self, request):
        # --- code here runs on the way IN (before the view) ---
        import time; start = time.time()

response = self.get_response(request)     # call the next layer (eventually the view)

# --- code here runs on the way OUT (after the view) ---
        response["X-Response-Time"] = f"{time.time() - start:.3f}s"
        return response
```

Middleware არის callable: კოდი `self.get_response(request)`-მდე Runner-ის request-ზე, კოდი მის შემდეგ რაც response-ზე. ეს საშუალებას გაძლევთ მოქმედებდეთ view execution-ის წინ და შემდეგ.

## Middleware-ის ჩვეულებრივი გამოყენება

```text
✓ Authentication / setting request.user
✓ Security headers (CSP, HSTS, X-Frame-Options)
✓ Request/response logging, timing, metrics
✓ Sessions, locale/i18n detection, CORS
✓ Rate limiting, maintenance mode, custom request preprocessing
```

## Middleware vs views/decorators

```text
Middleware → GLOBAL, cross-cutting concerns affecting EVERY (or most) request
Decorators/view logic → per-view concerns specific to certain endpoints
→ Use middleware for app-wide behavior; decorators for selective behavior.
```

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

Middleware ფუნდამენტალური იმისთვის, თუ როგორ ამუშავებს Django request-ებს — მისი გაგება ხსნის, თუ როგორ მუშაობს framework-ის ბევრი core functionality და იძლევა სწორ მექანიზმს **გლობალური, cross-cutting concerns-ებისთვის**.

შეგების, რომ sessions, authentication (`request.user`), CSRF protection, და security headers ყველა built-in middleware-დან მოდის, განმარტავს Django-ის request handling-ს და აჩვენებს, რატომ "უბრალოდ მუშაობს" ეს features. გაგება **onion-layer request/response flow**-ის (middleware wraps-ნებს view-ს, ამუშავებს requests top-to-bottom-ს და responses bottom-to-top-ს) და რომ **order აქვს მნიშვნელობა** (ზოგიერთი middleware დამოკიდებულია სხვაზე, როგორიცაა authentication, რომელიც უნდა sessions პირველი იყოს) აუცილებელია Django-ის სწორი კონფიგურირებისთვის და issues-ის debugging-ისთვის.

უნარი **custom middleware-ის დაწერა** მূল্యბადელია app-wide behavior-ის სუფთად განხორციელების საწ — logging, timing, custom headers, rate limiting, maintenance mode — ერთ ადგილას მის დანაცვლებაზე views-ში გამეორების.

მეტის იცოდე, როდის გამოიყენო middleware (გლობალური concerns, რომელიც გავლენას ახდენს უმეტეს requests-ებზე) versus decorators ან view logic (per-endpoint concerns) არის კლავიშური არქიტექტურული გადაწყვეტილება.

Middleware ის ის ადგილი, სადაც Django-ს აქვს request/response processing, რომელიც ვრცელდება მთელ აპლიკაციაზე, რაც მას მნიშვნელოვან, პრაქტიკული ცოდნის აკეთებს როგორც framework-ის internals-ის გაგებისთვის, ისე well-structured applications-ის აგებისთვის proper separation cross-cutting concerns-ის.