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 --json liste 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é#

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.

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 — il tient les huit stores du framework, comme `drizzle`	tu as besoin de clés étrangères ou de migrations versionnées : seul le SQL les tient
`@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, ou un schéma Mongoose sur une application MongoDB — mais seul le SQL tient des clés étrangères et des migrations versionnées. 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 à sa nature. Chaque adaptateur déclare les stores qu’il sait tenir (nodefony.stores de son package.json) : drizzle et mongoose les huit, redis quatre (session, tokens, passkeys, idempotency) — un cache ne garde pas un journal d’audit ni des comptes. Conséquence pratique : redis complète une base, il ne la remplace pas, 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, Svelte), 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é.

Intelligence artificielle#

Paquet	Prends-le quand…	Ne le prends pas si…
`@nodefony/ai`	tes modules exposent des outils à un agent (`getMcpTools()`, `mcpText`), ou tu écris toi-même une porte MCP : protocole, collecte et appel des outils	aucun agent ne parle à l’application

@nodefony/devkit tire @nodefony/ai : ses outils nodefony_* sont déclarés comme ceux de n’importe quel module.

🗂️ La documentation de chaque module#

Une fois le module choisi, sa documentation est installée avec lui — lis ciblé, jamais tout le dossier.

@nodefony/http Serveurs, contextes, sessions, TLS. le transport @nodefony/framework Routeur, contrôleurs, décorateurs. tu écris des routes @nodefony/security Pare-feu par zones, authentification, autorisation, audit. fermer l'application @nodefony/user Contrat IUser, stockage des comptes, mots de passe. les comptes @nodefony/orm-core Le contrat commun à tous les moteurs. le contrat @nodefony/drizzle SQL — PostgreSQL, MySQL/MariaDB, SQLite. le défaut @nodefony/mongoose MongoDB, données orientées document. document @nodefony/redis Cache, sessions partagées, backplane du temps réel. dès le 2ᵉ processus @nodefony/realtime Une connexion, N canaux bidirectionnels, backplane cluster. le serveur pousse @nodefony/frontend Build Vite, rechargement à chaud, React/Vue/Angular. servir une interface @nodefony/studio L'administration web : voir l'intérieur en marche. développement @nodefony/documentation Le portail qui rend ces pages, et son data plane. méta @nodefony/devkit Carte de visite de l'application, portes de découverte pour un agent. développement

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 --json le 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, le fichier .env, qui gagne : environnement.md
📖 Lexique général du framework.