Perché FastAPI è veloce e come lo mantieni tale?

Question

Accepted Answer

FastAPI è uno dei framework Python più veloci perché è costruito su **Starlette** (un framework ASGI leggero) ed è **async-native**, gestendo efficientemente molte richieste concorrenti I/O-bound. Ma mantenerlo veloce richiede di usare async correttamente — l'errore più comune è bloccare l'event loop.

## Perché è veloce

```text
✓ ASGI + Starlette — a modern async foundation (vs older WSGI sync frameworks)
✓ Async-native — one process handles thousands of concurrent I/O-bound requests
  by overlapping wait times, instead of one-at-a-time
✓ Pydantic v2 — validation/serialization core is now in Rust (very fast)
✓ Minimal overhead per request
```

Il modello async è la chiave: mentre una richiesta attende una query sul database o una chiamata API, il server gestisce altre — garantendo alto throughput per carichi di lavoro I/O-bound.

## Il #1 modo per mantenerlo veloce: non bloccare l'event loop

```python
# ❌ blocking call inside async def → freezes the event loop, serializing ALL requests
@app.get("/bad")
async def bad():
    return requests.get(url).json()       # SYNC/blocking → kills concurrency

# ✅ use an async client and await it
@app.get("/good")
async def good():
    async with httpx.AsyncClient() as c:
        return (await c.get(url)).json()  # non-blocking

# ✅ OR use a plain def — FastAPI runs it in a thread pool (safe for blocking code)
@app.get("/also-good")
def also_good():
    return requests.get(url).json()
```

Questa è la regola di performance più importante: una chiamata bloccante dentro `async def` blocca l'intero event loop, forzando le richieste a eseguirsi una alla volta. Usa librerie async con `await`, o una semplice `def` (eseguita in un thread pool).

## Mantenerlo veloce — la checklist

```text
✓ Use async DB drivers / async libraries (httpx, asyncpg) in async endpoints
✓ Run blocking code in plain def (thread pool) or via run_in_executor
✓ Avoid heavy CPU work on the event loop → offload to workers/processes
✓ Add caching (Redis) for expensive repeated work
✓ Optimize the database (fix N+1, add indexes) — often the real bottleneck
✓ Run multiple worker processes (uvicorn/gunicorn workers) to use all CPU cores
✓ Use connection pooling; paginate large results
✓ MEASURE first (profiling, load testing) — fix the actual bottleneck
```

## Perché è importante

La velocità di FastAPI è una ragione primaria per cui i team la scelgono, ma ottenere quella velocità in pratica dipende da **usare async correttamente** — e la regola più importante, frequentemente violata, è **non bloccare mai l'event loop**.

Capire *perché* FastAPI è veloce (fondazione ASGI async-native, concorrenza I/O efficiente, fast Pydantic v2 core) chiarisce che il suo vantaggio di performance si applica ai carichi di lavoro I/O-bound gestiti concorrentemente.

Sapere come *mantenerlo* veloce è la skill pratica critica: evitare l'errore devastante di mettere chiamate bloccanti in `async def` (che serializza tutte le richieste dietro un event loop congelato), usare librerie async negli endpoint async (o semplice `def` per codice bloccante), offloadare il lavoro CPU, caching, ottimizzare il database (spesso il vero collo di bottiglia), e eseguire più worker per più core.

Questa combinazione — sfruttare async correttamente e misurare per trovare veri colli di bottiglia — è quello che ti permette di realizzare il potenziale di performance di FastAPI, rendendola conoscenza importante a livello senior per costruire API genuinamente veloci e scalabili piuttosto che quelle che sembrano async ma performano come codice bloccante.