middleware ใน Django คืออะไร?

Question

Accepted Answer

**Middleware** เป็น framework ของ hook ที่ประมวลผล**ทุก request และ response**แบบ global โดยอยู่ระหว่าง web server และ view ของคุณ middleware แต่ละตัวสามารถตรวจสอบ/แก้ไข request ขาเข้าและ response ขาออกได้ — เหมาะสำหรับ concern แบบ cross-cutting เช่น authentication, security header, session และ 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)
```

## middleware ที่มีมาในตัวของ Django (ใน 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 คือ middleware: session (`request.session`), authentication (`request.user`), การป้องกัน CSRF และ security header ล้วนมาจาก 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)` รันบน request, โค้ดหลังจากนั้นรันบน response สิ่งนี้ช่วยให้คุณทำงานทั้งก่อนและหลังการรัน view

## การใช้งาน 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 เทียบกับ 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 ทำงานจริงอย่างไรและให้กลไกที่ถูกต้องสำหรับ **concern แบบ global และ cross-cutting**

การตระหนักว่า session, authentication (`request.user`), การป้องกัน CSRF และ security header ล้วนมาจาก middleware ที่มีมาในตัวช่วยไขความลึกลับของการจัดการ request ของ Django และแสดงว่าทำไมฟีเจอร์เหล่านี้จึง "ทำงานได้เลย" การเข้าใจ **request/response flow แบบชั้นหัวหอม** (middleware ห่อหุ้ม view โดยประมวลผล request จากบนลงล่างและ response จากล่างขึ้นบน) และการที่ **ลำดับมีความสำคัญ** (middleware บางตัวขึ้นอยู่กับตัวอื่น เช่น authentication ต้องการ session ก่อน) สำคัญต่อการตั้งค่า Django ให้ถูกต้องและการ debug ปัญหา

ความสามารถในการ **เขียน custom middleware** มีคุณค่าสำหรับการ implement พฤติกรรมระดับแอปอย่างสะอาด — logging, timing, custom header, rate limiting, maintenance mode — ในที่เดียวแทนการทำซ้ำข้าม view

การรู้ว่าเมื่อไรควรใช้ middleware (concern แบบ global ที่ส่งผลต่อ request ส่วนใหญ่) เทียบกับ decorator หรือตรรกะใน view (concern ต่อ endpoint) เป็นการตัดสินใจเชิงสถาปัตยกรรมที่สำคัญ

middleware เป็นที่ที่ Django จัดการการประมวลผล request/response ที่ใช้กับทั้ง application ทำให้มันเป็นความรู้ที่สำคัญและเกี่ยวข้องในทางปฏิบัติ ทั้งสำหรับการเข้าใจกลไกภายในของ framework และการสร้าง application ที่มีโครงสร้างดีด้วยการแยก concern แบบ cross-cutting ที่เหมาะสม