Django vs FastAPI su Cloudflare Workers: quale scegliere?

Django vs FastAPI su Cloudflare Workers: quale scegliere?

Scegli Django se hai già un'applicazione Django o ti serve un backend completo per un prodotto. Parti da FastAPI se devi creare da zero un'API tipizzata, un servizio webhook o un endpoint edge con molto I/O. Se un pacchetto indispensabile, il modello di processo o un carico con stato non è compatibile con il runtime Workers, lascia l'applicazione sull'origine attuale.

Cloudflare ha cambiato le premesse il 2 settembre 2026. Python Workers può ora ospitare direttamente applicazioni WSGI e ASGI tramite gli adapter del modulo workers. WSGI è il tradizionale contratto sincrono per il web in Python. ASGI è il successore asincrono, progettato per sovrapporre operazioni di I/O, gestire lo streaming e mantenere connessioni di lunga durata. Negli esempi pubblicati da Cloudflare, Django è associato esplicitamente a WSGI e FastAPI ad ASGI, anche se Django può usare entrambi i protocolli.

Django è l'opzione più prudente per una migrazione quando la sua piattaforma integrata produce già valore per il business. Cloudflare documenta ora entrypoint WSGI e ASGI, oltre a un percorso django-cf per D1 e Durable Objects.

FastAPI è la scelta più lineare per un progetto nuovo quando il risultato da realizzare è un'API, non un prodotto web supportato da un pannello di amministrazione. Cloudflare fornisce il livello server ASGI, quindi il Worker non deve eseguire Uvicorn né gestire un socket.

Sul prezzo è parità, finché non cambia il tempo CPU

Nessuno dei due framework offre un vantaggio di prezzo. Le tariffe sono state verificate il 5 settembre 2026 sulle pagine ufficiali attive: Django è gratuito e open source con licenza BSD, FastAPI usa la licenza MIT e Workers Paid parte da $5 per account al mese.

I $5 comprendono 10 milioni di richieste e 30 milioni di millisecondi CPU al mese. Le richieste aggiuntive costano $0.30 per milione, mentre la CPU aggiuntiva costa $0.02 per milione di millisecondi CPU. Le richieste per Static Assets sono gratuite e illimitate. Workers Free include 100,000 richieste al giorno, ma il limite di 10 ms di CPU per invocazione lo rende un riferimento poco adatto per confrontare applicazioni basate su framework non banali.

Applicando lo stesso carico a entrambi i framework, il risultato è volutamente poco sorprendente. Con 15 milioni di richieste dinamiche al mese e una media di 7 ms di CPU per richiesta, ciascun framework costa $8 al mese: $5 di base, $1.50 per le richieste eccedenti e $1.50 per la CPU eccedente. Con 100 milioni di richieste e la stessa media di 7 ms, il costo è $45.40 al mese per entrambi.

Il calcolo di sensibilità è più utile di un benchmark inventato tra framework. Una volta esaurito il monte CPU incluso per entrambe le applicazioni, ogni differenza media di 1 ms modifica la fattura di $0.30 con 15 milioni di richieste e di $2 con 100 milioni. Un divario misurato di 5 ms vale quindi $1.50 o $10 al mese a quei livelli di traffico. È troppo poco per giustificare la riscrittura di un framework basandosi soltanto sul costo di calcolo.

Non esiste un punto di pareggio legato al prezzo del fornitore. Una soluzione diventa più economica soltanto se cambiano il tempo CPU misurato, i servizi di supporto o l'onere di manutenzione. Un framework veloce attorno a chiamate lente al database non salverà l'architettura; al contrario, un framework integrato che evita settimane di lavoro per sostituirne le funzioni può risultare più conveniente anche quando un microbenchmark favorisce l'alternativa.

Migrazione: Django vince sui sistemi esistenti, FastAPI sulle nuove API

Cambiare l'adapter è semplice; migrare l'applicazione non lo è. A entrambi i framework basta un entrypoint sottile, ma tutto ciò che si trova dietro deve comunque rispettare il modello di Cloudflare per pacchetti, storage, filesystem e ciclo di vita.

Migrare Django su Cloudflare Workers: l'adapter è la parte facile

Django può conservare il proprio oggetto applicazione WSGI standard e passarlo all'adapter di Cloudflare:

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

Questo basta a trasferire una richiesta Workers in ingresso al callable WSGI di Django. Non migra però il database, i file persistenti, i job pianificati, la strategia delle sessioni né tutti i pacchetti Django di terze parti.

La nuova guida di Cloudflare al pacchetto Django offre al framework un percorso di storage realmente nativo. Il pacchetto django-cf mette a disposizione backend compatibili con SQLite per D1 e Durable Objects. Entrambi alimentano l'ORM sincrono di Django, perciò Cloudflare indica di servire questa configurazione tramite WSGI. In un prodotto CRUD che dipende già da modelli, form, autenticazione e admin, preservare questi livelli può far risparmiare molto più lavoro di quanto un cambio di framework possa ridurre i costi di runtime.

Il limite emerge quando il sistema esistente dà per scontato un server convenzionale. Un driver di database potrebbe richiedere una wheel nativa che Workers non può caricare. Gli upload degli utenti non possono risiedere nel filesystem dell'isolate. Non è possibile trasferire uno scheduler locale al processo o un thread pool. Il supporto a Django dimostra che il protocollo di richiesta funziona; non certifica l'intera applicazione installata.

Migrare FastAPI su Cloudflare Workers: ideale per un servizio mirato

L'adapter diretto di FastAPI è più essenziale perché il framework parla già ASGI:

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

Cloudflare svolge il ruolo di server ASGI normalmente affidato a Uvicorn. FastAPI mantiene la dichiarazione delle route, la validazione Pydantic, la dependency injection e la documentazione OpenAPI generata. Un nuovo ricevitore webhook, un'API JSON tipizzata o un servizio basato sui binding può quindi partire con meno componenti applicativi rispetto a Django.

Il compromesso è il lavoro di assemblaggio. FastAPI non impone volutamente un database o un modello dati e non include l'amministrazione dei contenuti di Django. Devi scegliere questi componenti, verificare ogni pacchetto rispetto all'ambiente Workers e gestirne l'integrazione. Per un servizio mirato è un vantaggio; per un prodotto i cui operatori necessitano di un back office fin dal primo giorno, è un costo.

Vincitore sulla migrazione: Django per un'applicazione già costruita con Django; FastAPI per una nuova API. Riscrivere in FastAPI un sistema Django funzionante soltanto perché ora entrambi possono girare all'edge significa scegliere il progetto sbagliato.

WSGI vs ASGI su Cloudflare: FastAPI vince sulla concorrenza, Django offre una scelta

ASGI è il modello di richiesta più adatto a un nuovo servizio con molto I/O, mentre WSGI è il percorso documentato per integrare l'ORM Django con Cloudflare. È il carico di lavoro a determinare il protocollo, non l'affermazione generica che l'asincrono sia sempre più veloce.

WSGI presenta l'applicazione come un callable sincrono. L'adapter WSGI attuale di Cloudflare esegue quel callable all'interno dell'handler asincrono fetch del Worker, trasferisce il corpo della richiesta da un ReadableStream JavaScript e invia al client in streaming l'iterabile di risposta dell'applicazione. È un percorso di compatibilità per applicazioni sincrone mature, non un secondo web server eseguito nell'isolate.

ASGI consente all'applicazione di attendere operazioni di rete e storage senza bloccare il percorso della richiesta con una chiamata sincrona. L'adapter Cloudflare mappa inoltre gli eventi ASGI WebSocket sui WebSocket di Workers. FastAPI nasce su questo modello. Anche Django può adottarlo, quindi «Django» e «WSGI» non sono sinonimi.

La scelta dello storage può ribaltare quella del protocollo. Cloudflare afferma che i backend D1 e Durable Objects per Django alimentano entrambi l'ORM sincrono e devono essere serviti tramite WSGI. Se Django viene scelto per il suo ORM, seguire il percorso WSGI documentato è più coerente che applicare un'etichetta ASGI a un livello dati sincrono.

Con FastAPI, l'asincrono offre vantaggi soltanto quando le operazioni possono sovrapporsi. Un endpoint che impiega quasi tutto il tempo nella validazione seriale o in calcoli Python pesanti continua a consumare CPU. Un endpoint in attesa di più operazioni HTTP indipendenti o di binding Cloudflare ha invece un motivo più chiaro per usare ASGI.

Avvio dell'applicazione: la sorpresa del lifespan di FastAPI

Su Workers, Django tramite WSGI offre oggi il modello di avvio più prevedibile. FastAPI funziona comunque, ma i suoi hook lifespan non si comportano come in un processo Uvicorn di lunga durata.

Cloudflare riduce il lavoro dei cold start Python usando snapshot creati al deploy. Durante il deployment, la piattaforma crea un isolate V8, inserisce Pyodide, esegue il modulo di ingresso del Worker e i suoi import al livello globale, quindi acquisisce uno snapshot della memoria WebAssembly. Una richiesta può caricare quello snapshot anziché ricostruire da zero l'ambiente Python. Il codice nello scope globale deve comunque essere analizzato ed eseguito entro il limite di avvio di 1 secondo imposto dalla piattaforma. Cloudflare documenta direttamente questo ciclo di vita.

Il normale contratto lifespan di FastAPI riflette il modello di un processo: il codice di startup viene eseguito una volta prima che l'applicazione accetti richieste, mentre quello di shutdown viene eseguito una volta al termine. Il codice sorgente dell'adapter ASGI Cloudflare attuale si comporta in modo sostanzialmente diverso. La sua funzione fetch avvia l'applicazione ASGI, invia un evento di startup del lifespan, gestisce una richiesta e infine invia lo shutdown. Il commento nel sorgente descrive un ciclo di startup e shutdown prima e dopo la richiesta.

Con l'adapter attuale, il codice lifespan diventa quindi circoscritto alla singola richiesta. Caricare un modello, creare un pool di connessioni, preparare uno schema o recuperare una configurazione remota in quella fase può ripetersi anziché essere ammortizzato nell'isolate. Non è un motivo per scartare FastAPI. Significa però che il lavoro nel lifespan deve essere leggero e idempotente, mentre l'inizializzazione deterministica e sicura va spostata nel codice che può sfruttare lo snapshot di deployment di Cloudflare.

Nell'esempio Cloudflare, l'applicazione WSGI di Django viene creata al livello del modulo e non prevede un ciclo lifespan ASGI. L'inizializzazione rientra quindi nel percorso di avvio globale, dove il vincolo è il limite di 1 secondo. Se scegli l'entrypoint ASGI di Django e utilizzi componenti consapevoli del lifespan, verificali rispetto allo stesso comportamento dell'adapter.

I framework per Python Workers incontrano lo stesso limite dei pacchetti

In questa categoria è parità, e il limite può escludere entrambi i framework. Django e FastAPI girano nello stesso ambiente Pyodide all'interno di V8, quindi nessuno dei due evita i vincoli relativi a pacchetti, memoria, filesystem o avvio.

La documentazione Cloudflare sui pacchetti spiega che pywrangler include nel bundle le dipendenze dichiarate in pyproject.toml. Le sorgenti supportate comprendono pacchetti Python puri e PyEmscripten provenienti da PyPI, oltre ai pacchetti distribuiti con Pyodide. PyEmscripten è il formato wheel destinato a WebAssembly. Cloudflare definisce ancora giovane questo ecosistema e alcuni pacchetti non dispongono di una wheel compatibile.

I vincoli essenziali della piattaforma sono chiari:

• Il bundle Worker non compresso non può superare 64 MiB né sul piano Free né su Paid.
• Ogni isolate dispone di 128 MB di memoria.
• L'avvio nello scope globale deve completarsi entro 1 secondo.
• Il filesystem Python è effimero e privato dell'isolate.
• È possibile importare threading e multiprocessing, ma questi moduli non funzionano nella VM WebAssembly.

Il vincolo del filesystem compromette più migrazioni di quanto lasci intuire la firma dell'adapter. I file temporanei non creano problemi. Upload persistenti, report generati, file SQLite usati come stato durevole e cache condivise su disco, invece, non sono compatibili. Conserva gli oggetti durevoli in D1, Durable Objects, KV o R2 in base al modello di accesso, non in una directory che scompare con l'isolate. I confini precisi sono descritti nella guida di Cloudflare alla libreria standard Python.

La compatibilità dei pacchetti è un requisito binario, da verificare prima di discutere le prestazioni. Compila il vero grafo delle dipendenze, non un sottoinsieme da hello world. Se un import riesce in CPython desktop, non significa che le sue estensioni native siano disponibili in Pyodide.

Compatibilità operativa: Django vince sui prodotti, FastAPI sui servizi

Django vince quando l'unità di lavoro è un prodotto; FastAPI quando è un servizio. Questa distinzione resiste meglio nel tempo rispetto al throughput dei framework su una route sintetica.

Per un prodotto con pannello di amministrazione vince Django

Django include autenticazione degli utenti, amministrazione dei contenuti, ORM, template, middleware e altre funzionalità comuni dei prodotti web. La sua panoramica ufficiale cita esplicitamente autenticazione e amministrazione dei contenuti. Se un piccolo team operativo deve gestire clienti, ordini, autorizzazioni e record editoriali, l'admin integrato può valere più di qualche millisecondo risparmiato nell'overhead del framework.

Su Workers, django-cf offre a questo modello integrato un percorso verso D1 o Durable Objects. Il prezzo da pagare è un legame più stretto con un ORM sincrono e una superficie del framework più ampia da far rientrare nei limiti del runtime.

Per un servizio API tipizzato vince FastAPI

FastAPI è costruito attorno a OpenAPI, JSON Schema, validazione Pydantic e dependency injection. Anche la sua documentazione delle funzionalità esplicita il compromesso: database e modelli dati restano scelte aperte. È la forma giusta per un gateway API, un ricevitore webhook, un endpoint per modelli o un piccolo servizio che comunica con binding e API remote.

L'assenza di un admin e di un ORM integrati non è un difetto se il servizio non ne ha bisogno. Diventa un costo di consegna nel momento in cui un operatore non tecnico necessita di un back office.

Per la velocità pura non c'è ancora un vincitore su Workers

Secondo la pagina dei benchmark di FastAPI, la suite indipendente TechEmpower ha storicamente collocato FastAPI con Uvicorn tra i framework Python più veloci. TechEmpower ha misurato carichi standardizzati per JSON, database, ORM, template e attività correlate. Non ha misurato gli adapter Pyodide di Cloudflare e il progetto è stato chiuso il 24 marzo 2026. Quei risultati rappresentano un segnale storico attribuito, non una previsione per un deployment su Workers.

Cloudflare non ha pubblicato benchmark tra Django e FastAPI eseguiti tramite questi adapter. Le prestazioni pure su Workers restano quindi non dimostrate finché una route rappresentativa non comprende validazione, binding, chiamate al database, formato della risposta, comportamento all'avvio e metriche CPU di Workers.

Quanto costa davvero cambiare e chi dovrebbe evitare di farlo

Non cambiare framework soltanto per ottenere il supporto di Cloudflare: ora entrambi lo offrono. Il passaggio ha senso esclusivamente quando il framework di destinazione elimina più lavoro applicativo di quanto ne generi la migrazione.

Riscrivere da Django a FastAPI significa sostituire o separare modelli, migrazioni, schermate di amministrazione, flussi di autenticazione, middleware, template e qualsiasi pacchetto basato sul ciclo di richiesta di Django. Il risultato può essere ottimo per un'API circoscritta, ma non è una semplice impostazione di deployment. Se admin e ORM sono usati intensamente, il passaggio distrugge il vantaggio esistente prima di crearne uno nuovo.

Passare da FastAPI a Django ha senso soltanto quando il prodotto ha superato un'architettura pensata come servizio e necessita della superficie operativa integrata di Django. In caso contrario, introduce convenzioni e componenti superflui per una piccola API.

FastAPI può montare un'applicazione WSGI Django sotto un percorso tramite a2wsgi.WSGIMiddleware. Sui server convenzionali, questo approccio può sostenere una separazione graduale. Su Workers aggiunge invece un altro pacchetto e un altro confine tra protocolli, mentre i percorsi iniziali documentati da Cloudflare tengono separati i due framework. Considera un Worker combinato un'integrazione personalizzata da dimostrare, non la scorciatoia predefinita.

Qualunque direzione tu stia valutando, calcola il costo di queste aree della migrazione:

• Dati: compatibilità dello schema, migrazioni, comportamento delle transazioni e passaggio a D1, Durable Objects o un altro archivio raggiungibile.
• File: gli asset statici possono usare Workers Static Assets, mentre i contenuti persistenti degli utenti richiedono uno storage durevole come R2.
• Lavoro in background: sostituisci scheduler locali al processo, thread pool e processi figli con il lavoro asincrono nativo della piattaforma.
• Dipendenze: risolvi l'intero lockfile rispetto a Python Workers, quindi controlla il bundle da 64 MiB e il risultato del limite di avvio di 1 secondo.
• Operazioni: ricostruisci log, avvisi di errore, rollback del deployment, secret e una baseline delle prestazioni per route.

Chi non dovrebbe cambiare? Un monolite Django stabile, con un database funzionante e workflow di amministrazione sostanziali, non dovrebbe diventare FastAPI per seguire una moda. Un servizio FastAPI che dipende da wheel native non disponibili non dovrebbe passare a Workers soltanto perché il framework ha ora una pagina nella documentazione. Un team la cui latenza dipende soprattutto da un database lontano dovrebbe correggere la collocazione dei dati prima di cambiare il framework che gestisce le richieste.

La prossima mossa: testare una route lunedì

La prossima settimana valida una route rappresentativa, non l'intera applicazione. Scegli quella che rispecchia le dipendenze, lo stato e la latenza del sistema in produzione, poi usala per eliminare rapidamente le opzioni sbagliate.

FAQ su Django e FastAPI su Cloudflare Workers