Django-bolt: Rust dentro Django per battere FastAPI in velocità

Il compromesso che nessuno voleva fare

Nell'articolo su FastAPI vs Django abbiamo parlato di un compromesso reale: chi vuole performance elevate sulle API deve rinunciare a Django ORM, Django Admin, e all'ecosistema di package che rende Django così produttivo. FastAPI è veloce — ma parte da zero su tutto il resto.

Django-bolt è un tentativo di rompere questo compromesso. L'idea è semplice quanto ambiziosa: portare un server HTTP scritto in Rust direttamente dentro Django, aggirando il GIL di Python per la gestione delle richieste, mantenendo però tutto l'ecosistema Django intatto.

È un progetto giovane — nato a ottobre 2025, alla v0.8.3 mentre scrivo. Ma è già abbastanza maturo da meritare attenzione.

Come funziona sotto il cofano

Per capire django-bolt serve capire tre componenti che lavorano insieme.

Actix Web

È il server HTTP in Rust che gestisce le connessioni. Actix Web è uno dei framework HTTP più veloci al mondo — nei benchmark TechEmpower si posiziona costantemente tra i primi posti in assoluto, non solo tra i framework Python. Gestisce le richieste in modo completamente asincrono su un runtime Tokio, senza i limiti del GIL Python.

PyO3

È il bridge che permette a Rust di chiamare codice Python e viceversa. Quando Actix Web riceve una richiesta, PyO3 la passa al tuo handler Python asincrono, raccoglie la risposta, e la rispedisce al client attraverso Actix. Il GIL viene acquisito solo durante l'esecuzione del codice Python, non per tutta la durata della connessione.

msgspec

È la libreria di serializzazione che sostituisce il JSON standard di Python. msgspec è 5-10 volte più veloce della stdlib per parsing e serializzazione — un dettaglio che su endpoint ad alto throughput fa una differenza concreta. I tuoi schema sono definiti come msgspec.Struct con type hints completi.

Il risultato di questa combinazione sono i benchmark che il progetto riporta: 188k RPS sull'endpoint root, 128k RPS con parsing e validazione JSON su payload da 10kb, 163k RPS con path e query parameters. Con ORM e database (SQLite, 10 record) si scende a circa 15k RPS — che rimane comunque competitivo.

Come si usa in pratica

L'API di django-bolt è deliberatamente familiare per chi conosce DRF o Django Ninja. Partiamo dal caso più semplice:

from django_bolt import BoltAPI
from django.contrib.auth import get_user_model
import msgspec

User = get_user_model()

api = BoltAPI()

class UserSchema(msgspec.Struct):
    id: int
    username: str
    email: str

@api.get("/users/{user_id}")
async def get_user(user_id: int) -> UserSchema:
    user = await User.objects.aget(id=user_id)
    return {"id": user.id, "username": user.username, "email": user.email}

Tre cose da notare: il decorator @api.get è identico a FastAPI, il return type annotation è usato per la validazione automatica della risposta, e User.objects.aget() è il Django ORM in versione asincrona — nessun adattatore, nessuna configurazione aggiuntiva.

Per aggiungere l'API al progetto Django, basta registrarla nelle urls.py:

from django.urls import path
from django_bolt import include_bolt
from myapp.api import api

urlpatterns = [
    path("api/", include_bolt(api)),
]

E per avviare il server si usa un management command dedicato:

python manage.py runbolt --host 0.0.0.0 --port 8000 --processes 4

Niente Gunicorn, niente Uvicorn. Il server è Actix Web.

ViewSet: migrazione da DRF senza strappi

Per chi ha già applicazioni DRF, django-bolt offre un pattern ViewSet molto simile:

from django_bolt import BoltAPI, ModelViewSet
from myapp.models import Progetto
from myapp.schemas import ProgettoSchema

api = BoltAPI()

class ProgettoViewSet(ModelViewSet):
    queryset = Progetto.objects.all()
    schema = ProgettoSchema

api.register_viewset("/progetti", ProgettoViewSet)

Questo genera automaticamente gli endpoint CRUD standard — GET /progetti/, POST /progetti/, GET /progetti/{id}/, PUT /progetti/{id}/, DELETE /progetti/{id}/ — con la logica di serializzazione gestita da msgspec.

Il sistema di permessi segue lo stesso pattern di DRF:

from django_bolt.permissions import IsAuthenticated, HasPermission

@api.get("/admin/report", guards=[IsAuthenticated(), HasPermission("view_report")])
async def get_report():
    ...

L'autenticazione JWT viene validata direttamente in Rust, senza passare per il GIL Python — il che contribuisce significativamente alle performance sugli endpoint autenticati.

I benchmark nella realtà

I numeri di django-bolt sono impressionanti sulla carta. 188k RPS sull'endpoint root. Ma è utile mettere quei numeri in contesto.

Il benchmark root è un endpoint che non fa nulla — restituisce una risposta statica. È il massimo teorico del framework, non un caso d'uso reale. L'endpoint con ORM scende a 15k RPS — che è comunque più veloce di DRF standard, ma non è 188k.

Per la maggior parte delle applicazioni Django reali, con query database, logica applicativa, serializzazione di oggetti complessi, il vantaggio di django-bolt si riduce rispetto ai benchmark sintetici. Rimane reale, ma è proporzionale alla percentuale di tempo che la tua applicazione passa nel layer HTTP rispetto al database e alla logica Python.

Dove django-bolt brilla davvero è su endpoint che ricevono molte richieste concorrenti con poco lavoro per richiesta — autenticazione, routing, serializzazione di dati semplici, streaming.

I limiti che non si possono ignorare

Django-bolt è alla v0.8.3. Il progetto stesso avvisa: "under active development, some features are not yet finalized." Non è un warning decorativo.

Alcune cose concrete da sapere prima di adottarlo:

La documentazione è in progress — il README e il sito ufficiale coprono i casi principali, ma per i casi edge devi spesso leggere il codice o aprire una discussion su GitHub.

Non tutto il middleware Django funziona automaticamente con django-bolt. L'integrazione con il middleware stack di Django è parziale — django-bolt ha il proprio sistema di middleware che non è un drop-in sostituto.

Il supporto per le sessioni Django e alcuni sistemi di autenticazione legacy richiede configurazione aggiuntiva rispetto a DRF.

Non è adatto per applicazioni che restituiscono principalmente template HTML — django-bolt è un framework API, non un sostituto delle views Django tradizionali.

Quando vale la pena considerarlo

Django-bolt ha senso in scenari specifici:

Hai un'applicazione Django esistente con endpoint API che sono diventati un collo di bottiglia misurato — non percepito, misurato. Hai profiling che mostra che il layer HTTP è il problema, non il database.

Stai costruendo un servizio con requisiti di throughput molto elevati — migliaia di richieste al secondo — dove il costo di migrare a FastAPI (abbandonare ORM, admin, ecosystem) è proibitivo.

Stai costruendo qualcosa di nuovo e vuoi sperimentare con tecnologia che ha un futuro promettente, accettando che potrebbe richiedere aggiustamenti al crescere delle versioni.

Non ha senso se la tua applicazione è principalmente template-driven, se il collo di bottiglia è il database, o se hai bisogno di stabilità production-grade immediata.

Un progetto da tenere d'occhio

Django-bolt è nato a ottobre 2025 e in meno di un anno ha raggiunto 1.5k stelle, 34 contributor, e uno sponsor enterprise (Baserow). La traiettoria è positiva.

Non è ancora il momento di migrare sistemi critici in produzione senza una valutazione approfondita. Ma è già il momento di tenerlo d'occhio, di sperimentarlo su progetti interni, e di capire se la direzione che sta prendendo — Rust per le performance, Django per la produttività — è quella giusta per il tuo contesto.

Il compromesso tra velocità ed ecosistema non è ancora del tutto risolto. Ma per la prima volta qualcuno sta cercando di risolverlo davvero.