Nidus : le framework Rust qui mise tout sur l'explicite

Avouons-le : les frameworks backend Rust ont une sale réputation. Soit tu pars de zéro avec rien, soit tu récupères un monstre qui cache tout derrière des conventions obscures impossibles à débugger. Nidus prend un chemin différent. Et c'est plutôt rafraichissant.

L'explicite avant tout

Le principe de base de Nidus ? Ta structure applicative doit apparaître dans ton code source. Point barre. Pas de configs générées, pas de decorators magiques qui apparaissent au runtime.

Ils appellent ça le module graph — et c'est exactement ce que ça veut dire. Une structure visible et inspectable : imports, providers, controllers, exports. Tout ça, tu le vois.

Concrètement, quand quelque chose plante, tu trouves le problème. Quand tu veux comprendre comment une dépendance traverse ton service, tu lis le code. Pas les logs qui essaient de reverse-engineer ce que le framework a décidé au démarrage.

L'injection de dépendances typée, correctement

Tu as déjà utilisé un conteneur DI dans un autre langage ? Tu sais que ça repose souvent sur des clés en string, de la réflexion, ou du "convention over configuration".

Nidus fait autrement. Il exploite directement le système de types de Rust.

Tu enregistres tes dépendances par type, avec des patterns qui collent à Rust :

• Singletons pour l'état partagé
• Request-scoped pour les données par requête
• Lazy pour l'initialisation différée
• Optional pour une dégradation élégante
• Factories pour les constructions complexes

Le mieux ? Tout est typé. Le compilateur détecte les erreurs avant tes utilisateurs.

Une couche HTTP qui se compose proprement

Nidus s'appuie sur Axum et Tower, qui sont des choix solides dans l'écosystème Rust. Mais il les enveloppe dans une couche où la composition devient explicite.

Tes routes, middleware, guards et pipes de validation sont définis dans le code. Tu vois l'ensemble du tableau.

Pour la validation, ils utilisent Garde. Ça te donne des erreurs stables et prévisibles. Et la génération OpenAPI part directement de tes définitions de routes — pas d'une documentation séparée qui finit toujours par diverger de la réalité.

Les chiffres, sans fioritures

Passons aux choses sérieuses. L'équipe Nidus a comparé leur framework à FastAPI, Spring Boot et Express. Même contexte : homelab Kubernetes, PostgreSQL identique, même contrat d'endpoint.

Les résultats :

• Latence ping la plus rapide : 423,72 microsecondes
• Zéro requête échouée
• Meilleur débit en écriture : 423,94 requêtes par seconde

Ce que j'apprécie vraiment : l'équipe reste prudente dans ses claims. Ils expliquent exactement comment ils ont testé, où, et quoi mesurer. Pas de marketing agressif. Juste les faits de leur homelab.

L'approche "narrow facade"

Philosophiquement, Nidus se distingue par ce qu'ils appellent la narrow facade. Le framework ne t'impose pas de dépendances vendor par défaut.

Tu veux SQLx ? Un crate adapter séparé. Du caching ? Un autre crate adapter. Le cœur reste léger, et tu choisis ce dont tu as besoin.

Pourquoi c'est important ?

1. Ton arbre de dépendances reste propre
2. Tu accèdes directement aux clients sous-jacents, sans couches d'abstraction qui bouffent tes performances
3. Mettre à jour ou remplacer une dépendance ne signifie pas se battre avec des changements au niveau framework

Démarrer rapidement

Le framework promet de faire passer un développeur Rust senior de zéro à running en moins d'une minute. Le répertoire d'exemples confirme : des services allant du hello-world à des APIs prêtes pour la production avec adapters et templates externes.

L'approche release est同样 pragmatique. Les dry-runs locaux vérifient que tout fonctionne avant publication. Le CLI inspector, TestApp et le dashboard optionnel te permettent de vérifier ta structure de routes, ton module graph et ta sortie OpenAPI au runtime.

Nidus est-il fait pour toi ?

Si tu construis des services backend en Rust et que tu privilégies :

• L'explicite plutôt que les conventions magiques
• La sécurité de type plutôt que la découverte au runtime
• Un footprint de dépendances léger plutôt que "tout et son contraire" par défaut

Alors Nidus mérite ton attention.

Ce n'est pas le framework qui fait tout à ta place. C'est le framework qui se met en retrait tout en fournissant la rigueur structurelle qui garde les grandes bases de code maintenables.

Pour les équipes qui ont toujours souhaité que le développement web Rust soit plus explicite sans être moins puissant — tu as peut-être trouvé ce que tu cherchais.

Jette un œil aux exemples, lance le CLI inspector, et décide par toi-même si cette approche "explicite par défaut" correspond à ta philosophie de développement.