La domanda sbagliata

"FastAPI è più veloce di Django?" è la domanda che apre quasi ogni confronto tra i due framework. È anche la domanda sbagliata.

Sì, FastAPI è più veloce in benchmark sintetici — async nativo, overhead minimo, Starlette come base. Ma la velocità di un framework è raramente il collo di bottiglia di un'applicazione reale. Il collo di bottiglia è quasi sempre il database, la logica applicativa, o le chiamate a servizi esterni. Un'applicazione Django ben ottimizzata supera una FastAPI mal progettata in qualsiasi scenario reale.

La domanda giusta è: per questo caso d'uso specifico, quale framework mi dà quello di cui ho bisogno senza costringermi a costruire da zero quello che non include?

FastAPI vs Django: quando usare l'uno o l'altro

Django: batterie incluse, e si sente

Django esiste dal 2005. In vent'anni ha accumulato un ecosistema che copre quasi tutto quello che serve per costruire un'applicazione web complessa:

  • ORM con migration automatiche
  • Sistema di autenticazione e autorizzazione
  • Admin interface generata automaticamente dai modelli
  • Form handling e validazione
  • Internazionalizzazione
  • Sistema di template
  • Gestione dei file statici e media
  • Middleware stack configurabile
  • Signals per la comunicazione tra componenti

Tutto questo è disponibile, documentato, e testato da milioni di applicazioni in produzione. Non devi scegliere una libreria per l'ORM, una per l'auth, una per le migration — sono già lì, integrate e coerenti tra loro.

Il prezzo di queste batterie è l'opinione: Django ha un modo di fare le cose, e allontanarsi da quel modo richiede sforzo. Se stai costruendo qualcosa che si adatta bene al modello Django — un'applicazione con modelli dati complessi, logica di business articolata, interfaccia di amministrazione — quella opinione è un vantaggio, non un limite.

FastAPI: esplicito, veloce, e scarno di default

FastAPI è nato nel 2018 con un obiettivo preciso: costruire API Python ad alte prestazioni con il minimo overhead. Async nativo, validazione automatica dei dati con Pydantic, documentazione OpenAPI generata automaticamente, type hints come contratto.

Quello che FastAPI non include è tutto il resto. Nessun ORM (puoi usare SQLAlchemy, Tortoise, o qualsiasi altro), nessun sistema di auth integrato, nessuna admin interface, nessun sistema di migration. Ogni componente lo scegli e lo integri tu.

Questo non è un difetto — è una scelta di design. FastAPI è un framework per costruire API, non applicazioni web complete. La sua leggerezza è un vantaggio nei contesti giusti.

Tre casi d'uso concreti

Gestionale aziendale con permessi complessi

Stai costruendo un sistema interno per gestire pratiche, utenti con ruoli diversi, documenti, workflow di approvazione. Gli utenti si autenticano, hanno permessi granulari sulle risorse, c'è un'interfaccia di amministrazione per il backoffice.

La scelta è Django.

L'ORM gestisce i modelli dati complessi e le relazioni tra entità. django-guardian o il sistema di permessi nativo coprono i permessi object-level. L'admin interface è pronta in poche righe. Django REST Framework espone le API per il frontend. La logica di business vive nei modelli e nei service layer. Costruire tutto questo da zero con FastAPI significherebbe reinventare quello che Django già ha — con più codice, più scelte, più possibilità di errore.

Skara, il gestionale per enti pubblici che ho costruito, è esattamente questo caso: Django 5.1, django-guardian per i permessi, DRF per le API REST, Celery per i task asincroni. FastAPI non avrebbe aggiunto nulla e avrebbe tolto molto.

API per un'app mobile con alto throughput

Stai costruendo il backend di un'app mobile — autenticazione JWT, endpoint REST o GraphQL, gestione notifiche push, integrazione con servizi terzi. Nessuna interfaccia di amministrazione, nessun template, solo dati in entrata e in uscita.

FastAPI ha senso qui.

Async nativo gestisce molte connessioni concorrenti con meno thread. Pydantic valida automaticamente input e output con type hints. La documentazione OpenAPI viene generata senza configurazione aggiuntiva. Se il team ha già familiarità con async Python, FastAPI permette di costruire API performanti con codice conciso e ben tipizzato.

Django con DRF regge benissimo anche in questo contesto — lo fanno in produzione molte applicazioni ad alto traffico. Ma se parti da zero, non hai bisogno dell'ORM di Django, non hai bisogno dell'admin, non hai bisogno del sistema di template: FastAPI ti dà quello che ti serve senza il resto.

Backend ML/AI con inferenza in tempo reale

Stai costruendo un servizio che espone un modello di machine learning — image classification, NLP, raccomandazioni — con endpoint che ricevono dati, chiamano il modello, e restituiscono risultati. Latenza bassa, throughput alto, nessuna logica di business complessa.

FastAPI è la scelta naturale.

L'ecosistema Python ML (PyTorch, HuggingFace, scikit-learn) si integra direttamente senza adattatori. Async permette di gestire richieste mentre il modello elabora in background. La leggerezza del framework si traduce in startup time basso e footprint ridotto — importante in ambienti containerizzati dove scalare orizzontalmente significa avviare molte istanze.

Django in questo contesto porterebbe overhead inutile — stai pagando per l'ORM, l'admin, il middleware stack, senza usarne nessuno.

Il ruolo di Django REST Framework

Prima di concludere che Django non è adatto per API, vale la pena capire cosa aggiunge Django REST Framework.

DRF trasforma Django in un framework API di prima classe: serializzatori con validazione, viewset che generano automaticamente gli endpoint CRUD, autenticazione JWT o token integrata, paginazione, filtering, throttling. La curva di apprendimento è reale, ma il risultato è un'API robusta e ben strutturata con meno codice di quanto sembri.

Per chi conosce già Django, DRF è spesso la scelta più rapida per costruire API anche complesse — senza abbandonare l'ORM, il sistema di permessi, e tutto il resto dell'ecosistema.

Possono coesistere

Un pattern che funziona bene in certi contesti è usarli insieme: Django come applicazione principale con DRF per la maggior parte delle API, e FastAPI montato come sub-applicazione per gli endpoint ad alte prestazioni o per i servizi ML.

# main.py — FastAPI monta Django come sub-applicazione
from fastapi import FastAPI
from django.core.wsgi import get_wsgi_application

fastapi_app = FastAPI()
django_app = get_wsgi_application()

# endpoint FastAPI ad alte prestazioni
@fastapi_app.get("/api/v2/inference")
async def inference(data: InferenceRequest):
    ...

# Django gestisce il resto via middleware

Non è una soluzione per tutti i progetti — aggiunge complessità di deployment. Ma per applicazioni che hanno sia logica di business complessa che endpoint ad alto throughput, è un compromesso ragionevole.

La scelta

Django quando hai bisogno di tutto: modelli dati complessi, auth, admin, workflow articolati, e vuoi costruire velocemente su fondamenta solide.

FastAPI quando costruisci API pure, microservizi, o servizi ML dove l'overhead di Django non porta valore e la performance async è rilevante.

DRF quando sei già su Django e hai bisogno di API robuste senza cambiare stack.

La velocità del framework è l'ultimo criterio da considerare. Il primo è quello che devi costruire.