O que é middleware no Django?

Question

Accepted Answer

**Middleware** é um framework de hooks que processa **cada requisição e resposta** globalmente, ficando entre o servidor web e suas views. Cada middleware pode inspecionar/modificar requisições na entrada e respostas na saída — ideal para preocupações transversais como autenticação, headers de segurança, sessões e logging.

## O fluxo de requisição/resposta através de 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 integrado do Django (em 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
```

Muita da funcionalidade principal do Django é middleware: sessões (`request.session`), autenticação (`request.user`), proteção CSRF e headers de segurança vêm todos do middleware integrado. **A ordem importa** — alguns middleware dependem de outros serem executados primeiro.

## Escrevendo middleware customizado

```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
```

Um middleware é um callable: código antes de `self.get_response(request)` é executado na requisição, código depois é executado na resposta. Isso permite que você atue tanto antes quanto depois da execução da view.

## Usos comuns de 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/decoradores

```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.
```

## Por que isso importa

Middleware é fundamental para como Django processa requisições — entender isso explica como muita da funcionalidade principal do framework realmente funciona e fornece o mecanismo correto para **preocupações globais e transversais**.

Reconhecer que sessões, autenticação (`request.user`), proteção CSRF e headers de segurança vêm todos do middleware integrado desmistifica o tratamento de requisições do Django e mostra por que essas funcionalidades "funcionam naturalmente". Entender o **fluxo em camadas de cebola de requisição/resposta** (middleware envolvendo a view, processando requisições de cima para baixo e respostas de baixo para cima) e que **a ordem importa** (alguns middleware dependem de outros, como autenticação precisando de sessões primeiro) é importante para configurar Django corretamente e debugar problemas.

A capacidade de **escrever middleware customizado** é valiosa para implementar comportamento amplo da aplicação de forma limpa — logging, timing, headers customizados, rate limiting, modo de manutenção — em um só lugar em vez de repetir isso através de views.

Saber quando usar middleware (preocupações globais afetando a maioria das requisições) versus decoradores ou lógica de view (preocupações por endpoint) é uma decisão arquitetural chave.

Middleware é onde Django trata processamento de requisição/resposta que se aplica através de toda a aplicação, tornando-o conhecimento importante e praticamente relevante tanto para entender os internals do framework quanto para construir aplicações bem estruturadas com separação apropriada de preocupações transversais.