Backend Python e FastAPI — API moderne e scalabili
FastAPI è il framework Python di riferimento per le API REST asincrone. Unisce le annotazioni di tipo native di Python alla validazione automatica con Pydantic, alla documentazione OpenAPI generata da sola e all'architettura ASGI, senza rinunciare alla leggibilità del codice.
FastAPI: il framework Python per API asincrone
FastAPI gira su Uvicorn (server ASGI) con Gunicorn per la modalità multiprocesso in produzione. Un endpoint semplice che legge dalla cache Redis evita di interrogare il database a ogni richiesta. La dependency injection nativa consente di testare ogni livello in isolamento senza mock complicati: autenticazione, sessione del database e rate limiting sono ciascuno una dipendenza iniettabile.
La documentazione OpenAPI 3.1 viene generata automaticamente dalle annotazioni di tipo: in sviluppo, Swagger UI e ReDoc sono disponibili su `/docs` e `/redoc`. Lo schema Pydantic v2 (validatore scritto in Rust) convalida richieste e risposte. Qualsiasi campo non valido restituisce un 422 con messaggi di errore chiari e localizzati.
- async/await nativo: I/O non bloccante su tutte le operazioni verso database e HTTP
- BackgroundTasks per il lavoro successivo alla risposta (e-mail, webhook, log)
- Supporto nativo per i WebSocket nelle funzioni in tempo reale (chat, notifiche)
- Rate limiting con slowapi (basato su limits): per IP e per utente
- Middleware per CORS, compressione (gzip/brotli), request ID e misurazione dei tempi
PostgreSQL, SQLAlchemy e Alembic
Per tutte le operazioni sul database usiamo SQLAlchemy 2.0 async (driver asyncpg). I modelli sono definiti con i Mapped type: tipizzati in modo sicuro, senza stringhe. Le query complesse si scrivono in SQLAlchemy Core (verificato in fase di compilazione) oppure in SQL puro tramite `text()` con parametri associati, mai per interpolazione di stringhe: il rischio di SQL injection è così escluso del tutto.
Le migrazioni Alembic vengono generate automaticamente dalle modifiche ai modelli e riviste a mano prima dell'applicazione. Ogni migrazione ha `upgrade()` e `downgrade()` testati. In produzione le migrazioni girano in CI prima del rilascio, così il database resta sempre allineato al codice. Il pool di connessioni è gestito da asyncpg, con dimensione configurabile per ciascun servizio.
- Lock a livello di riga con `SELECT ... FOR UPDATE` per le operazioni concorrenti critiche
- Ricerca full-text con pg_trgm e tsvector: senza Elasticsearch nei casi semplici
- JSONB per dati semi-strutturati, con indici GIN
- Tabelle partizionate per tabelle da milioni di righe (log, eventi)
Cache Redis e scalabilità orizzontale
Redis 7 viene usato come cache applicativa (TTL per endpoint), archivio di sessione (refresh token JWT con revoca selettiva), pub/sub per gli eventi in tempo reale e coda per i job in background (Celery oppure ARQ). La strategia di cache è cache-aside con invalidazione esplicita, non un TTL cieco che rischierebbe di servire dati non aggiornati.
- Autenticazione JWT con access token (15 minuti) e refresh token su Redis (7 giorni)
- Celery con Redis come broker per le attività asincrone (generazione PDF, e-mail, importazioni)
- Endpoint di health check `/health` con lo stato di database, Redis e versione rilasciata
- Logging strutturato in JSON (structlog), compatibile con Loki, Datadog ed ELK
Vantaggi e limiti
Vantaggi
- Architettura ASGI asincrona per le operazioni di I/O.
- Documentazione OpenAPI generata automaticamente dalle annotazioni di tipo.
- Validazione con Pydantic v2 ed errori 422 chiari.
- Codice leggibile: Python è familiare alla maggior parte dei team.
Limiti
- Python resta più lento di Go o Rust sulle attività a forte uso di CPU.
- async/await richiede disciplina: una sola chiamata bloccante ferma l'intero event loop.
- Ecosistema più giovane di Django per le funzionalità già incluse.
- Non comprende né ORM né pannello di amministrazione: si scelgono separatamente.
Verdetto in breve
Scegli FastAPI per API REST asincrone, microservizi e backend di applicazioni SPA o mobili. Per carichi estremamente intensivi sulla CPU o per monoliti con pannello di amministrazione già pronto, possono risultare più adatti rispettivamente Go e Django.
Tabella delle specifiche
| Capacità | Limite / soglia | Uso tipico | |
|---|---|---|---|
| Concorrenza | async/await, I/O non bloccante | Il lavoro a forte uso di CPU richiede worker separati | API con molte chiamate a database e HTTP |
| Latenza | Endpoint con cache Redis, senza query ripetute sul database | Cresce con la serializzazione di payload di grandi dimensioni | Backend SaaS, mobile e in tempo reale |
| Validazione e documentazione | Pydantic v2 e OpenAPI 3.1 automatico | Gli schemi complessi allungano l'avvio | API pubbliche con Swagger o ReDoc |
| Costo tipico | Open source, gira su 1 vCPU | La scalabilità orizzontale richiede più processi | Dall'MVP alla produzione |
FastAPI a confronto con le alternative
| Criterio | FastAPI | Django / Express |
|---|---|---|
| Prestazioni asincrone | Asincrone per natura (ASGI nativo) | Django in parte, Express buone |
| Documentazione OpenAPI automatica | Sì, dalle annotazioni di tipo | Richiede pacchetti aggiuntivi |
| Amministrazione e ORM inclusi | No (si scelgono separatamente) | Django: sì; Express: no |
Domande frequenti
FastAPI è più veloce di Django?
Sulle operazioni di I/O sì. FastAPI gira in modo asincrono su ASGI e gestisce quindi molte più richieste concorrenti con chiamate a database o HTTP rispetto al Django sincrono classico. Django, in compenso, offre più funzionalità già incluse.
Per che cosa FastAPI non è adatto?
Per le attività a forte uso di CPU (elaborazione di immagini, calcolo numerico pesante) Python è più lento di Go o Rust: quel lavoro si sposta su worker separati. Inoltre non porta con sé un pannello di amministrazione pronto come quello di Django.
FastAPI ha bisogno di un ORM?
Non necessariamente. Noi usiamo SQLAlchemy 2.0 async con Alembic per le migrazioni, ma è possibile scrivere anche SQL puro. L'ORM non è incluso, quindi lo si sceglie in base al progetto.
Come si scala un backend FastAPI?
In orizzontale: si eseguono più processi Uvicorn sotto Gunicorn, dietro un bilanciatore di carico, con cache Redis e le attività pesanti spostate su Celery. Il design stateless permette di aggiungere istanze quando serve.