Architecture du CMS
Le CMS autonome, la plateforme séparée et leurs contrats versionnés.
Sur cette page
Une instance autonome
Bracten gère un site par instance. Node HTTP assemble l’administration React, l’API et le renderer public côté serveur. PostgreSQL est la source de vérité. Installation, connexion, publication et extensions installées fonctionnent sans service central.
Frontières du workspace
| Chemin | Responsabilité |
|---|---|
| cms | Composition des services, HTTP dans cms/http et CLI directement dans ce dossier. |
| cms/core | Domaines du contenu, médias, site, extensions, thèmes et sauvegardes ; façades des primitives partagées. |
| cms/database | Façade PostgreSQL du CMS vers les transactions, baux et migrations partagés. |
| cms/providers | Adaptateurs hôtes S3, Redis et SMTP, sans client technique incorporé dans les packages d’extensions. |
| cms/admin | Administration React et son bundle navigateur. |
| sdk/src | Contrats publics, validateurs, documents, champs et composants de thème, sous le nom @bracten/sdk. |
| server/src | Primitives GPL communes d’identité, MFA, récupération, tâches, e-mails, PostgreSQL et formats de packages. |
| runtime/src | Gestionnaire autonome des versions du core et de leur reprise. |
| bracten-platform / apps/central | Dépôt propriétaire séparé : compte, registre signé, catalogue gratuit et portail éditeur, avec base et authentification propres. |
| themes/* et extensions/official/* | Modules compilables qui utilisent le SDK public. |
| bracten-platform / apps/docs et apps/marketing | Sites du dépôt propriétaire. La documentation consomme une référence API exportée et versionnée, sans importer le serveur CMS. |
Le dépôt bracten contient quatre composants principaux, cms, sdk, runtime et server, ainsi que ses thèmes et extensions GPL. Les sources serveur se trouvent directement dans cms et compilent dans cms/dist, avec les sous-dossiers core, database et providers. Le SDK, le runtime et les primitives partagées conservent leurs dossiers src et dist. Les extensions utilisent les entrées publiques de @bracten/sdk, pas les façades internes du CMS.
Le CMS et la centrale réutilisent @bracten/server, qui dépend du SDK ; les domaines métier restent dans le CMS. La centrale ne dépend ni du cœur CMS, ni du runtime, ni des clients AWS ou Redis. Chaque dépôt possède son installation de dépendances, sa compilation et sa CI ; aucun chemin vers un checkout voisin n’est requis.
L’export plateforme de schéma 2 contient uniquement @bracten/sdk et @bracten/server, avec leurs empreintes, licences, sources GPL et référence API. L’inventaire sourceFiles couvre aussi cms, sdk, runtime et server pour vérifier les liens de ces guides. Référencer un fichier du CMS ou du runtime ne crée pas une dépendance de l’application documentation vers son code.
Chemin d’une mutation
- Le serveur vérifie méthode, origine et taille du corps.
- Le routeur contrôle la session, le CSRF et la permission, ou le jeton Bearer sur les seules routes qui l’autorisent. Les scopes sont plafonnés aux droits actuels de l’utilisateur.
- Le service valide l’entrée et relit les droits sous verrou.
- Versions, schémas, références, hooks, contenu et révision sont vérifiés dans la transaction.
- Le handler retourne une réponse conforme à son contrat ou une erreur structurée avec requestId. Les refus de domaine ou de transport peuvent survenir avant ce handler.
Concurrence et diffusion
Les versions détectent les écrasements concurrents. Les copies privées de contenu et de site restent séparées des publications. Les migrations de schémas vérifient et transforment les contenus atomiquement, sans réécrire les snapshots historiques.
La visibilité des contenus réservés est filtrée en SQL avant les résultats, compteurs et facettes. Renderer, relations, archives, recherches, sitemap et API officielles l’appliquent. Les réponses dépendantes d’une session utilisent private, no-store et Vary: Cookie ; aucun cache global de pages n’est activé.
Le serveur et les commandes CLI qui ouvrent l’application partagent un bail exclusif. Arrêtez le serveur avant ces commandes. cms update utilise au contraire l’API du serveur actif. Les objets média et d’extension sont immuables ; sauvegarde et rétention utilisent un verrou d’archive commun.
Services et confiance
E-mails, tâches et planifications sont durables dans PostgreSQL. Le cœur garde stockage local, cache en mémoire, validation et capture d’e-mails. Les extensions S3, Redis et SMTP enregistrent leurs factories SDK à partir de la version 0.1.2 ; leur activation précède une sélection explicite dans l’environnement serveur et un redémarrage. Les anciens sélecteurs s3, redis et smtp restent compatibles. Redis ne remplace pas la file de tâches. Le contrat des providers précise leurs frontières.
Un plugin ou thème JavaScript possède les droits du processus ; le SDK n’est pas une sandbox. Les services centraux sont facultatifs et ne sont pas publiés en production par la seule compilation du dépôt. Paiements, licences commerciales et Cloud restent absents.