Un framework sincrono in un mondo asincrono
Per quindici anni Django ha costruito la propria identità attorno a un modello di esecuzione sincrono: una richiesta arriva, viene elaborata dall’inizio alla fine su un singolo thread e produce una risposta. L’approccio è prevedibile, facile da debuggare e compatibile con l’intero ecosistema di middleware, ORM e librerie costruite sulla certezza che ogni operazione si completi prima della successiva.
Ma il mondo delle applicazioni web è cambiato. WebSocket, server-sent events, chiamate a servizi esterni con latenze imprevedibili e architetture a microservizi rendono il modello sincrono un vincolo. Framework come FastAPI e Starlette, costruiti nativamente su asyncio di Python, dimostrano che la concorrenza asincrona migliora il throughput su carichi I/O-bound senza richiedere più thread o processi.
Django 3.0 e il supporto ASGI
Con la versione 3.0, rilasciata nel dicembre 2019, Django introduce il supporto per ASGI (Asynchronous Server Gateway Interface), il successore asincrono di WSGI. ASGI permette di servire Django tramite server asincroni come Daphne o Uvicorn, aprendo la porta alla gestione concorrente di connessioni long-lived.
La scelta architetturale è deliberatamente conservativa: Django 3.0 può essere servito via ASGI, ma le view, il middleware e l’ORM restano sincroni. Il framework esegue il codice sincrono in un thread pool all’interno del loop asincrono, mantenendo la compatibilità con tutto il codice esistente. Non si tratta di una riscrittura: è un’apertura graduale.
Le prime view asincrone
Django 3.1, rilasciato nel successivo agosto 2020, compie il passo successivo introducendo le async view: funzioni di vista dichiarate con async def che possono utilizzare await per operazioni non bloccanti. Un endpoint che deve attendere la risposta di un’API esterna o di un servizio può ora farlo senza bloccare il thread, liberando risorse per gestire altre richieste.
Il middleware riceve un percorso di migrazione analogo: Django supporta middleware sia sincrono sia asincrono, e il framework gestisce automaticamente la transizione tra i due mondi quando necessario. I segnali e il sistema di autenticazione restano sincroni nella 3.1, con la migrazione prevista nelle versioni successive.
L’ORM resta sincrono — per ora
L’ORM è il componente più complesso da migrare: le query al database sono intrinsecamente bloccanti, e il sistema di QuerySet, manager e relazioni è costruito su operazioni sincrone. Django 3.x mantiene l’ORM sincrono, utilizzando sync_to_async come ponte quando invocato da codice asincrono. La roadmap prevede un’interfaccia ORM asincrona nativa nelle versioni future, ma la priorità è non rompere la compatibilità con le applicazioni esistenti.
Migrazione graduale come strategia
La strategia di Django riflette una filosofia chiara: aprire alla concorrenza senza imporre una riscrittura. Le applicazioni esistenti continuano a funzionare senza modifiche. I nuovi endpoint possono essere asincroni dove il beneficio è concreto. Per le organizzazioni con codebase Django consolidate, questo approccio incrementale riduce il rischio e permette di adottare l’asincrono dove conta davvero.
Link: djangoproject.com