Django இல் middleware என்றால் என்ன?

Question

Accepted Answer

**Middleware** என்பது வலை சேவையகத்திற்கும் உங்கள் views களுக்கும் இடையில் உட்கார்ந்து **ஒவ்வொரு request மற்றும் response ஐயும்** உலகளாவியாக செயலாக்கும் hooks களின் ஒரு கட்டமைப்பு. ஒவ்வொரு middleware யும் requests களை பரிசோதிக்கவோ/மாற்றவோ முடியும் மற்றும் responses களை திருத்தமாக வெளியேற்றலாம் — இது authentication, security headers, sessions, மற்றும் logging போன்ற cross-cutting concerns களுக்கு சிறந்தது.

## Middleware மூலம் request/response flow

```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 இன் பெரும்பாலான core functionality middleware ஆகும்: sessions (`request.session`), authentication (`request.user`), CSRF protection, மற்றும் security headers அனைத்தும் built-in middleware இலிருந்து வருகிறது. **Order முக்கியமுள்ளது** — சில 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)` க்கு முன் உள்ள code request இல் செயல்படுகிறது, அதற்குப் பிறகு உள்ள code response இல் செயல்படுகிறது. இது view execution க்கு முன்பும் பிறகும் செயல்பட உங்களை அனுமதிக்கிறது.

## Common middleware uses

```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 எவ்வாறு requests களை செயலாக்குகிறது என்பதற்கு அடிப்படையாகும் — இது framework இன் பெரும்பாலான core functionality எவ்வாறு உண்மையில் செயல்படுகிறது என்பதை விளக்குகிறது மற்றும் **global, cross-cutting concerns** களுக்கு சரியான வழிமுறையை வழங்குகிறது.

Sessions, authentication (`request.user`), CSRF protection, மற்றும் security headers அனைத்தும் built-in middleware இலிருந்து வருகிறது என்பதை அங்கீகரிப்பது Django இன் request handling ஐ தெளிவுபடுத்துகிறது மற்றும் இந்த features கள் ஏன் "just work" செய்கிறது என்பதைக் காட்டுகிறது. **Onion-layer request/response flow** ஐ புரிந்துகொள்ளுதல் (middleware view ஐ சுற்றியுள்ளது, requests களை top-to-bottom மற்றும் responses களை bottom-to-top செயலாக்குகிறது) மற்றும் **order முக்கியமுள்ளது** (சில middleware authentication க்கு sessions முதலில் தேவை போன்ற மற்றவற்றை சார்ந்துள்ளது) Django ஐ சரியாக configure செய்வதற்கும் சிக்கல்களைத் தீர்ப்பதற்கும் முக்கியமுள்ளது.

**Custom middleware எழுதுவதற்கான** திறன் app-wide behavior ஐ சுத்தமாக செயல்படுத்துவதற்கு மূல்யமுள்ளது — logging, timing, custom headers, rate limiting, maintenance mode — ஒரு இடத்தில் views களில் அதை மீண்டும் செய்வதை விட.

Middleware (global concerns பெரும்பாலான requests களை பாதிக்கும்) மற்றும் decorators அல்லது view logic (per-endpoint concerns) ஐ எப்போது பயன்படுத்துவது என்பதை தெரிந்துகொள்ளுதல் ஒரு முக்கியமான architectural decision ஆகும்.

Middleware என்பது Django request/response processing ஐ முழு application முழுவதும் பயன்படுத்தும் இடமாகும், இது framework இன் internals களைப் புரிந்துகொள்ளுவதற்கும் சரியான separation of cross-cutting concerns உடன் well-structured applications களை கட்டமைப்பதற்கும் முக்கியமான, practically-relevant knowledge ஐ செய்கிறது.