Catalogue des modules — quel module pour quel besoin
stablenodefony (cœur)mis à jour 2026-07-25
📍 Documentation › Cœur — @nodefony/core › Catalogue des modules
Nodefony ne fournit pas UNE façon de tout faire : il fournit un socle, et des modules qu’une application déclare. Cette page répond à la seule question qu’on se pose avant d’écrire du code : quel paquet installer pour ce besoin, et lequel ne PAS installer. Elle est publiée avec le cœur — une application l’a donc sous la main dans
node_modules/nodefony/docs/catalogue.md, sans réseau ni dépôt.
🧭 Par où commencer#
- Trouve ton besoin dans les familles ci-dessous — chaque entrée dit aussi quand ne PAS prendre le module, ce qu’aucune page de vente ne fait.
- Déclare-le (trois pas, section suivante).
- Vérifie sur pièce :
nodefony inspect modules --jsonliste ce qui est réellement chargé.
Déclarer un module — le geste, une fois pour toutes#
Trois pas, toujours les mêmes :
npm install @nodefony/<module>
// nodefony.config.ts — manifeste `modules`
use("@nodefony/<module>", {/* options */});
nodefony inspect modules --json # ce qui est RÉELLEMENT chargé, sans ouvrir de port
Les clés de configuration ne sont pas dans cette page — et c’est voulu : elles vivent dans le
schéma du module, node_modules/@nodefony/<module>/dist/nodefony/config/config.js, où chaque clé
porte son défaut et sa description. Une page qui les recopierait mentirait à la première évolution.
nodefony inspect config <module> en donne la valeur effective et sa provenance.
Le socle — présent dans toute application#
Ces trois-là ne se choisissent pas : nodefony create app les pose.
| Paquet | Ce qu’il apporte |
|---|---|
nodefony |
Le cœur : Service, conteneur d’injection, Kernel, Module, journal, CLI, client isomorphe |
@nodefony/http |
Serveurs HTTP/HTTP2/WebSocket, contextes de requête, sessions, TLS |
@nodefony/framework |
Routeur, contrôleurs, décorateurs de route, idempotence |
Sécurité & identité#
<!-- prettier-ignore -->
| Paquet | Prends-le quand… | Ne le prends pas si… |
|---|---|---|
@nodefony/security |
une partie de l’application doit être fermée : zones de pare-feu, six méthodes d’authentification, autorisation par voters, CSRF/CORS, 2FA, passkeys, journal d’audit | l’application est entièrement publique — mais la fermer plus tard coûte alors une reprise des routes |
@nodefony/user |
tu veux des comptes utilisateurs (contrat IUser, encodeurs de mot de passe) sans dépendre du pare-feu |
l’identité vient d’ailleurs (jeton d’un fournisseur externe, service amont) |
@nodefony/security embarque déjà @nodefony/user : le déclarer seul n’a de sens que pour gérer
des comptes sans fermer de routes.
Données#
Un contrat commun, plusieurs implémentations : écris contre le contrat, choisis le moteur ensuite.
<!-- prettier-ignore -->
| Paquet | Prends-le quand… | Ne le prends pas si… |
|---|---|---|
@nodefony/orm-core |
jamais directement — c’est le contrat, tiré par l’adaptateur que tu choisis | — |
@nodefony/drizzle |
le défaut : SQL (PostgreSQL, MySQL/MariaDB, SQLite), nodefony create entity cible lui |
tes données sont des documents sans schéma stable |
@nodefony/mongoose |
MongoDB, données orientées document | tu as besoin d’un des stores qu’il ne fournit pas : il en couvre 5 (session, user, tokens, passkeys, webhooks) là où drizzle en couvre 8 — totp, audit et idempotency lui manquent |
@nodefony/redis |
cache, sessions partagées entre pods, backplane du temps réel en cluster | un seul processus : les sessions en mémoire et le backplane local suffisent |
L’arbitrage qui revient le plus souvent : drizzle ou mongoose ? Le générateur d’entités
(nodefony create entity) produit du Drizzle natif du dialecte ; partir sur Mongoose, c’est écrire
ses modèles à la main. Prends mongoose parce que tes données SONT des documents, pas pour éviter
de choisir un dialecte SQL.
La couverture d’un adaptateur est ADAPTÉE, pas identique. Chaque adaptateur déclare les
stores qu’il sait tenir (nodefony.stores de son package.json) : drizzle les huit,
mongoose cinq, redis quatre. Ce n’est pas un retard de développement mais un choix — stocker
un journal d’audit ou un verrou d’idempotence dans un moteur documentaire n’a pas de sens partout.
Conséquence pratique : un adaptateur ne remplace pas l’autre, ils se complètent, et
nodefony inspect stores dit où chaque donnée atterrit RÉELLEMENT dans ton application.
Et redis ? Il ne sert à rien tant que l’application tourne dans un seul processus. Il devient
nécessaire à l’instant où il y en a deux : sans lui, deux pods ont deux annuaires de sessions et
deux hubs temps réel qui ne se parlent pas.
Temps réel & interface#
| Paquet | Prends-le quand… | Ne le prends pas si… |
|---|---|---|
@nodefony/realtime |
le serveur doit pousser : une connexion qui multiplexe N canaux bidirectionnels, actions RPC, backplane cluster | un simple echo WebSocket suffit — @nodefony/http le fait déjà |
@nodefony/frontend |
l’application sert une interface Vite (React, Vue, Angular), en rechargement à chaud en développement et pré-construite en production | l’application n’est qu’une API |
@nodefony/studio |
tu veux voir l’intérieur en marche : routes, services, configuration, sessions, journaux, en développement | production — c’est un outil de développement, pas un tableau de bord public |
@nodefony/documentation |
tu publies des pages de documentation servies par l’application elle-même | tu écris de la documentation lue seulement dans le dépôt |
@nodefony/devkit |
tu développes l’application avec un agent : carte de visite de l’application, portes de découverte de l’outillage | production — ce qu’il expose n’y est plus une aide, mais une divulgation |
@nodefony/studio tire @nodefony/frontend : le déclarer suffit à avoir les deux.
@nodefony/devkit se déclare policy: "dev" : hors développement, il n’est même pas importé.
🗂️ La documentation de chaque module#
Une fois le module choisi, sa documentation est installée avec lui — lis ciblé, jamais tout le dossier.
Ce que ce catalogue ne dit pas#
- Les clés de configuration — elles vivent dans le schéma du module (voir plus haut). Les recopier ici les périmerait.
- Les versions — une publication les fixe toutes ensemble ;
npm install @nodefony/<module>prend celle qui correspond à ton cœur. - Ce que ton application charge vraiment —
nodefony inspect modules --jsonle dit, et lui ne peut pas se tromper.
🔗 Pour aller plus loin#
- ⬆️ Retour au hub : Cœur — @nodefony/core
- 🧭 Le cycle de vie qui charge ces modules : kernel.md · les commandes qui les interrogent : cli.md
- ⚙️ Régler un module sans toucher au code — variables, cascade des
.env, précédence : environnement.md - 📖 Lexique général du framework.