Développer une plateforme d’automatisation multilocataire sans mélanger locataires ni éditions

## Séparer les données de chaque locataire et garder le code premium hors de l’édition communautaire Traitez la portée du locataire, les éditions du produit, l’accès aux fonctions et l’identité visuelle comme des contrats de sécurité et de comportement. ### Imposer l’isolement - Modélisez explicitement la propriété aux niveaux de la plateforme, du projet et de l’utilisateur. - Limitez chaque requête de base de données à l’aide de l’identifiant correct du projet ou de la plateforme ; ne comptez jamais sur le fait que l’appelant filtrera les résultats plus tard. - Exigez une déclaration de contrôle d’accès pour chaque endpoint. - Appliquez l’autorisation du backend et le middleware de fonctions avant le comportement protégé, renvoyez la réponse standard `402` pour les fonctions payantes indisponibles et reproduisez la même restriction dans la protection du frontend et dans l’activation des requêtes. ### Conserver une dépendance dirigée entre éditions - Permettez aux éditions premium ou hébergées d’étendre le cœur communautaire au moyen de hooks ou d’interfaces enregistrés. - N’importez jamais de code applicatif réservé à l’édition premium dans le code communautaire. - Conservez des valeurs par défaut sans marque pour l’édition communautaire, appliquez l’identité visuelle configurée dans les environnements hébergés et limitez l’identité visuelle de l’édition entreprise auto-hébergée selon la capacité de forfait appropriée. - Vérifiez le comportement visible par les clients sur 5 parcours : édition communautaire auto-hébergée, édition entreprise auto-hébergée, édition hébergée gratuite, édition hébergée payante et édition entreprise hébergée. - Faites dépendre tous les noms, couleurs, logos, écrans de connexion et messages visibles par les clients de l’apparence configurée plutôt que d’une marque de produit codée en dur. ## Déclarer les dépendances par espace de travail et verrouiller les données partagées entre serveurs Rendez explicites la propriété des dépendances et le comportement concurrent des données afin que la réussite locale corresponde au déploiement en production. ### Maintenir les limites des paquets - Ordonnez les bibliothèques partagées depuis des fondations légères et indépendantes du framework jusqu’aux paquets lourds du niveau applicatif. - Les intégrations réutilisables et les moteurs d’exécution ne doivent dépendre que de paquets légers ; exposez le comportement applicatif nécessaire par une couche de framework étroite. - Déclarez chaque dépendance d’exécution dans l’espace de travail qui l’importe, et chaque dépendance de test ou d’outillage dans les dépendances de développement de cet espace de travail. - Réservez le manifeste racine à l’outillage de l’ensemble du dépôt ou aux véritables exigences d’amorçage. - Épinglez les versions de façon cohérente et mettez à jour le fichier de verrouillage avec l’outil d’installation canonique après toute modification des dépendances. ### Protéger la persistance et la concurrence - Enregistrez explicitement les nouvelles entités lorsque le mappeur d’objets ne les découvre pas automatiquement. - Séparez les effets de bord dans des modules dédiés et invoquez-les explicitement après la réussite des mutations. - Pour les tâches réparties sur plusieurs serveurs, utilisez un verrou distribué, la déduplication de file d’attente ou le verrouillage de lignes avec la sémantique `skip-locked`. - Évitez les extensions de base de données indisponibles sur les services gérés. - Assainissez les objets fournis de l’extérieur avant de les stocker dans la base de données. ## Éviter any et les conversions de type forcées, et utiliser les utilitaires partagés du projet Utilisez des interfaces, des flux de données, une organisation des fichiers et des utilitaires partagés prévisibles. ### Préserver l’intégrité des types - N’utilisez pas `any` ; utilisez des types exacts ou `unknown` avec des gardes de type. - Ne forcez pas les valeurs par des conversions de type. Corrigez le type source, ajoutez une validation ou affinez le type de la valeur. - Consultez la documentation de la bibliothèque avant d’utiliser une API et remplacez tout élément marqué comme obsolète. - Utilisez un paramètre objet unique et déstructuré pour toute fonction comportant plus de 1 paramètre. - Privilégiez un flux de données immuable entre les fonctions ; créez et renvoyez de nouvelles collections au lieu de modifier les objets appartenant à l’appelant. ### Rendre les conventions explicites - Utilisez les utilitaires de résultat partagés du projet pour la gestion synchrone et asynchrone des erreurs. - Transformez les messages de validation visibles par les utilisateurs en clés de localisation ; utilisez des clés partagées pour les erreurs courantes de formulaire et créez de nouvelles clés si nécessaire. - Après avoir vérifié la branche actuelle, augmentez la version corrective d’un paquet partagé pour les corrections ou ajouts compatibles et sa version mineure pour les nouvelles exportations ou les nouveaux comportements. - Définissez les utilitaires non exportés comme des fonctions autonomes, placez d’abord la logique exécutable et regroupez les constantes et les types exportés à la fin au lieu de les intercaler avec la logique. - Commentez la raison d’une décision, et non ce que fait un code explicite par lui-même. - Exportez plusieurs utilitaires simples au moyen de 1 objet nommé, tout en conservant les composants React sous forme d’exportations nommées. ## Faire passer le HTTP sortant par le client sûr pour bloquer les SSRF et suivre les règles de l’API Appliquez une sémantique de requête explicite et des clients réseau sûrs à chaque limite non fiable. ### Normaliser les endpoints - Utilisez `POST` pour toutes les mutations de création et de mise à jour, et `DELETE` pour les suppressions ; n’utilisez jamais `PUT` ou `PATCH` lorsque le contrat de l’API les exclut. - Donnez à chaque endpoint une configuration explicite de sécurité et d’accès. - Utilisez les identifiants, types d’erreur, bases de schémas, utilitaires de collection et outils d’assainissement de base de données canoniques au lieu de les réimplémenter. ### Empêcher la falsification de requêtes côté serveur - Faites passer les requêtes HTTP sortantes des composants serveur par le client sûr approuvé. - N’utilisez jamais `fetch` directement ni une fabrique de clients sans restriction pour les URL provenant d’une entrée utilisateur, d’une configuration d’administrateur, d’endpoints OAuth ou d’intégrations tierces. - Maintenez le filtrage des adresses privées, de bouclage et de métadonnées du cloud. - Conservez la conversion des types, la validation des URL et l’assainissement des objets externes à la limite. ### Traiter les migrations comme des changements contrôlés - Lisez le guide de migration du dépôt avant de créer ou de modifier une migration. - Suivez le processus documenté de génération et de structure au lieu d’inventer l’organisation de la migration. - Maintenez les migrations compatibles avec l’environnement de base de données géré pris en charge. ## Afficher la boîte de dialogue d’erreur globale seulement si les données principales de la page échouent N’affichez les échecs globaux de requête que lorsque les données en échec sont essentielles à la page actuelle. ### Classer les requêtes selon leur impact - Définissez l’indicateur de métadonnées de requête qui déclenche la boîte de dialogue d’erreur globale pour les données principales de la page, comme les lignes d’un tableau ou les listes principales. - Ne l’activez pas pour les données auxiliaires telles que les indicateurs de fonctions, les métadonnées, les recherches individuelles, les options de filtre ou les renseignements sur l’utilisateur. - Appliquez cette règle de décision : affichez la boîte de dialogue si l’échec laisserait autrement une page blanche inexpliquée ou une vue principale vide. - Laissez les requêtes mineures échouer discrètement lorsque l’interface environnante reste utile. - Maintenez les requêtes soumises à une fonction désactivées jusqu’à ce que la capacité de forfait correspondante soit disponible. ## Tester l’isolement des locataires et chaque édition avec l’exécuteur de tâches du monorepo Exécutez des tests ciblés avec l’exécuteur de tâches canonique du dépôt unique et vérifiez les parcours qui diffèrent selon l’édition. ### Exercer le code et les données - Exécutez des tests unitaires pour le code partagé et le code d’exécution, ainsi que des tests d’intégration pour le comportement de l’API. - Utilisez les utilitaires standard d’environnement de test et de contexte de requête afin que l’authentification et le routage correspondent au comportement de production. - Veillez à isoler les données de test et à les nettoyer entre les tests. - Ajoutez des tests de concurrence lorsque le code utilise des verrous, la déduplication ou une sélection de base de données avec `skip-locked`. - Testez l’isolement des locataires en prouvant que les données d’un autre projet ou d’une autre plateforme ne peuvent pas être renvoyées. ### Utiliser les commandes prises en charge - Exécutez la commande obligatoire de contrôle et de correction du lint du dépôt avant de considérer la tâche comme terminée. - Utilisez l’exécuteur de tâches configuré du dépôt unique et les commandes filtrées par paquet ; n’invoquez pas un système de construction sans rapport. - Lorsqu’un frontend hébergé pointe vers un backend distant, évitez les flux OAuth qui redirigent vers le domaine hébergé ; utilisez des identifiants sans redirection ou un backend entièrement local. - Vérifiez les restrictions d’édition, l’identité visuelle, les limites et la disponibilité des fonctions sur tous les parcours pris en charge. ## Étiqueter le changement et ne terminer qu’après la réussite des vérifications obligatoires Utilisez la documentation des fonctions, les étiquettes et les vérifications finales pour rendre le changement compréhensible et publiable. ### Préparer la mise en œuvre - Avant de modifier une fonction, lisez sa documentation ciblée sur les entités, les services, les flux de données et les contraintes d’intégration. - Gardez les règles de sécurité transversales critiques concises et séparez-les des processus fonctionnels détaillés étape par étape. - Vérifiez les manifestes de dépendances, l’enregistrement des entités, les filtres de locataire, les importations entre éditions, les déclarations d’accès et l’ordre des effets de bord. ### Préparer la contribution - Appliquez exactement 1 étiquette principale de changement distinguant une fonction, une correction de bogue ou un changement interne exempté du journal des modifications. - Ajoutez une étiquette distincte de domaine d’intégration lorsque le changement affecte une intégration tierce ou centrale. - Confirmez que le fichier de verrouillage, la version du paquet, les clés de localisation, les tests et les artefacts générés correspondent à la mise en œuvre. - Exécutez les contrôles obligatoires de lint, de test et de sécurité et signalez tout contrôle qui n’a pas pu être exécuté. - Ne déclarez pas l’achèvement tant que la différence finale et les résultats de vérification ne le justifient pas.