Nidus: il framework Rust backend che non gioca con la magia
Nidus: il framework Rust che non nasconde le cose
Diciamolo chiaro: i framework Rust per backend hanno sempre avuto un problema. O ti lasciano a metà strada, costringendoti a scrivere tutto da zero, oppure diventano così "magici" che non capisci più cosa succede sotto il cofano. Nidus prende una terza via, e quella che molti sviluppatori Rust esperti potrebbero apprezzare.
La trasparenza come filosofia
Il cuore di Nidus è semplice: tutto quello che riguarda la struttura della tua applicazione deve essere visibile nel codice. Niente file di configurazione generati, niente decoratori cheappaiono solo a runtime.
Il framework chiama questo approccio "module graph". È esattamente quello che sembra: una struttura che puoi ispezionare, dove vedi imports, providers, controllers ed exports.
Quando qualcosa si rompe, lo trovi. Quando devi capire come una dipendenza si muove attraverso il tuo servizio, leggi il codice. Non ti perdi nei log di runtime cercando di ricostruire cosa ha deciso il framework all'avvio.
Dependency injection che ha senso
Se hai lavorato con container DI in altri linguaggi, sai già il problema: chiavi stringa, reflection, convenzioni che non capisci. Nidus fa diversamente. Usa il sistema di tipi di Rust.
Registri le dipendenze per tipo, con pattern che sono naturali in Rust:
- Singleton per lo stato condiviso
- Request-scoped per i dati legati a ogni richiesta
- Lazy per inizializzazione rinviata
- Optional per degradazione elegante
- Factory per costruzione complessa
Il risultato? Tutto è tipizzato. Il compilatore becca gli errori prima degli utenti.
Il layer HTTP che si compone bene
Nidus si appoggia su Axum e Tower, scelte solide nell'ecosistema Rust. Ma le avvolge in uno strato che rende la composizione esplicita. Route, middleware, guards e pipe di validazione sono tutti definiti nel codice. Vedi tutto.
Per la validazione usano Garde, che dà errori stabili e prevedibili. La generazione OpenAPI parte dalle definizioni delle route, non da documentazione separata che inevitabilmente diverge dalla realtà.
I numeri sulla performance
Qui la cosa si fa interessante. Il team di Nidus ha fatto benchmark contro FastAPI, Spring Boot ed Express. Stesso setup Kubernetes homelab, stessi endpoint con PostgreSQL.
I risultati:
- Latency ping più veloce: 423.72 microsecondi
- Zero richieste fallite
- Throughput migliore su write-heavy: 423.94 richieste al secondo
Ma quello che apprezzo è l'onestà. Il team specifica esattamente come hanno testato, dove, e cosa hanno misurato. Nessun numero di marketing gonfiato. Solo i dati dal loro homelab.
Il narrow facade
Un'altra cosa che distingue Nidus è quello che chiamano "narrow facade". Il framework non trascina dipendenze vendor di default. Serve SQLx? C'è un adapter crate separato. Vuoi caching? Altro adapter crate.
Il core resta leggero. Tu scegli cosa aggiungere.
Perché importa:
- L'albero delle dipendenze resta pulito
- Accedi direttamente ai client sottostanti, senza layer di astrazione che mangiano performance
- Aggiornare o sostituire una dipendenza non significa combattere con cambiamenti a livello framework
Si inizia in fretta
Il framework promette di portare un senior Rust engineer da zero a running in meno di un minuto. La directory degli esempi conferma: servizi che vanno dall'hello-world ad API pronte per produzione, con adapter e template esterni.
L'approccio al rilascio è altrettanto concreto. Dry-run locali verificano che tutto funzioni prima di pubblicare. La CLI inspector, TestApp e la dashboard opzionale ti permettono di verificare struttura delle route, module graph e output OpenAPI a runtime.
Nidus fa per te?
Se stai costruendo backend in Rust e valorizzi:
- Esplicito sopra implicito
- Type safety sopra discovery a runtime
- **Dependency footprint snello sopra "prendiamo tutto di default"
Allora Nidus merita la tua attenzione.
Non cerca di essere il framework che fa tutto per te. Cerca di essere il framework che si mette da parte, pur dando la rigidità strutturale che mantiene grandi codebase manutenibili. Per team che hanno desiderato uno sviluppo web Rust più esplicito senza essere meno potente, potrebbe essere quello che aspettavi.
Dai un'occhiata agli esempi, lancia la CLI inspector, e vedi se l'approccio "explicit by default" si adatta alla tua filosofia di sviluppo.