Come funziona il request lifecycle in FastAPI?

Question

IT Interview Practice · Accepted Answer

FastAPI gira su **ASGI**, quindi una request attraversa una pipeline async: l'ASGI server la accetta, il middleware la avvolge, il router abbina un path, **le dependency vengono risolte**, la tua path operation viene eseguita, e il valore di ritorno viene serializzato nella response.

## Le fasi

```
uvicorn (ASGI server)
   │  scope + receive/send
   ▼
ASGI / Starlette middleware  ── (CORS, GZip, custom)
   ▼
Routing  ── abbina method + path → path operation
   ▼
Dependencies (Depends)  ── risolvi sub-deps, security, yield-setup
   ▼
Path operation function  ── viene eseguito il tuo handler
   ▼
Response model  ── valida + serializza in JSON
   ▼
Background tasks  ── eseguiti dopo l'invio della response
   ▼
Response ──▶ client
```

1. **ASGI server** (uvicorn/hypercorn) accetta la connessione e passa uno `scope` più i callable `receive`/`send` all'app.
2. **Middleware** viene eseguito dall'esterno verso l'interno in entrata e dall'interno verso l'esterno in uscita (`BaseHTTPMiddleware` o middleware ASGI puro). CORS, GZip e il timing personalizzato vivono qui.
3. **Routing** abbina il metodo HTTP + path a una path operation; i parametri path/query/body vengono estratti e validati da **Pydantic**.
4. **Dependency injection** — `Depends(...)` risolve ogni dependency (DB session, utente corrente, settings), con caching all'interno della request. Una dependency con `yield` esegue il setup prima e il teardown dopo l'handler.
5. **Path operation** — la tua `async def` (o `def`, eseguita in un threadpool) esegue la logica di business.
6. **Response** — il valore di ritorno viene forzato al `response_model` dichiarato, validato e serializzato in JSON; vengono applicati status code e header.
7. **Background tasks** registrati tramite `BackgroundTasks` vengono eseguiti *dopo* l'invio della response.

```python
from fastapi import FastAPI, Depends, Request

app = FastAPI()

@app.middleware("http")
async def timing(request: Request, call_next):   # 2. middleware
    response = await call_next(request)
    response.headers["X-Time"] = "..."
    return response

async def get_db():                               # 4. dependency (yield)
    db = Session()
    try:
        yield db
    finally:
        db.close()

@app.get("/items/{id}")                           # 3. routing
async def read_item(id: int, db=Depends(get_db)): # 5. handler
    return db.get(Item, id)                        # 6. serializzato tramite response_model
```

Le eccezioni vengono catturate dagli **exception handler** (`@app.exception_handler(...)` / `HTTPException`), che le convertono in response invece di far crashare la request.

## Perché è importante

Il request lifecycle è dove le funzionalità di punta di FastAPI accadono davvero: async I/O, validazione Pydantic e dependency injection si agganciano tutte a fasi specifiche. Conoscere l'ordine — middleware, poi routing, poi dependency, poi handler, poi serializzazione — ti permette di mettere la logica trasversale nel posto giusto (auth come dependency, timing come middleware, cleanup in una dependency `yield`), di fare il debug del perché un errore di validazione o di auth scatta prima che giri il tuo codice, e di evitare di bloccare l'event loop dentro un handler async.

Le fasi

Perché è importante

Domande correlate