Une plateforme de contenu multi-locataire.
Un éditeur de blocs, un moteur de rendu public, une application de compte pour les utilisateurs finaux et un plan de contrôle, au-dessus d'une couche de paquets partagée. Quatre surfaces qui doivent s'accorder sur un document, un locataire et une permission : c'est tout le problème d'ingénierie.
Quatre surfaces, une seule vérité.
L'utilisateur modifie un document. Un navigateur finit par recevoir une page. Ce sont des artefacts différents, produits par un code différent, à des moments différents, et un outil de création est digne de confiance exactement dans la mesure où il les maintient d'accord. Un aperçu qui dérive, une annulation qui restaure un état que le modèle n'aurait jamais dû autoriser, une modification de modèle qui réécrit en silence des documents créés avec la version précédente : chacun est mineur isolément, et ensemble ils expliquent pourquoi les gens abandonnent un outil de création pour retourner écrire du balisage.
Le multi-locataire reprend ce même problème et le répète dans toutes les autres dimensions. Qui peut modifier cette page, vers quel espace de travail ce domaine personnalisé résout-il, sur quelle offre se trouve cet espace de travail, et cette clé d'API voit-elle quoi que ce soit qu'elle ne devrait pas voir. Chacune de ces questions est un endroit où deux représentations d'un même fait peuvent se contredire.
Le travail intéressant n'est donc pas l'expérience d'édition. C'est de savoir où chaque fait a le droit de vivre, et si la conception rend la mauvaise réponse inatteignable plutôt que simplement déconseillée.
Les exigences qui en découlent.
Pas une liste de fonctionnalités. Ce sont les propriétés que le système devait tenir pour que la catégorie fonctionne.
- Un modèle de blocs sur lequel l'éditeur et le moteur de rendu ne peuvent pas diverger
- Chaque enregistrement récupérable, et pas seulement le dernier
- Des permissions décidées à un seul endroit plutôt que vérifiées à chaque point d'appel
- Une isolation des locataires qu'une clause WHERE oubliée ne peut pas mettre en défaut
Où chaque fait a été contraint de vivre.
Quatre choix qui ont façonné la plateforme, chacun avec un contraire défendable que de nombreux produits retiennent.
Présentés comme des décisions plutôt que comme des fonctionnalités, parce que chacune a un coût. Voici dans quel sens celle-ci a tranché et ce que cela a permis.
Les blocs sont déclarés une fois et l'union est générée
Un bloc déclare son type, son schéma de validation, ses valeurs par défaut, son éditeur et son moteur de rendu dans une seule définition. Un manifeste liste les blocs qu'inclut un build, et la génération de code en tire l'union de schémas sur laquelle tout le reste est validé. L'alternative, une union de types maintenue à la main, dérive dès que quelqu'un ajoute un bloc et met à jour trois des quatre endroits concernés.
Chaque enregistrement écrit une version, il n'en écrase pas une
Enregistrer ajoute une ligne de version numérotée contenant un instantané complet du document et de ses métadonnées, avec l'auteur et l'heure. L'historique, la comparaison et le retour arrière s'appuient alors sur un enregistrement qui existe déjà plutôt que sur une pile d'annulation qui disparaît avec l'onglet du navigateur. Cela coûte du stockage, ce qui est la chose la moins chère qui soit échangée ici.
Les permissions passent par un seul moteur de règles
Les rôles, les politiques et le déploiement progressif des fonctionnalités sont évalués à un seul endroit au lieu d'être re-vérifiés à chaque point d'appel. Des contrôles dispersés sont lisibles un par un et impossibles à auditer ensemble : personne ne peut dire ce qu'un rôle peut réellement faire sans lire toutes les routes qui le mentionnent.
L'isolation des locataires est une propriété du schéma, pas une convention
Les espaces de travail, les organisations, les équipes et le routage des domaines sont modélisés comme de vraies relations avec de vraies contraintes, de sorte que l'isolation est garantie par la base de données plutôt que par chaque auteur qui se souvient du même filtre. L'approche inverse fonctionne parfaitement jusqu'à la requête qui l'oublie.
La décision qui a compté.
Un choix par réalisation, fait avec une vraie alternative sur la table. L'alternative est nommée ici, et le coût d'avoir choisi contre elle aussi.
Un modèle de document contraint, pas un canevas libre.
Le modèle n'autorise que les documents que le moteur de rendu sait rendre. Il est impossible de créer dans l'éditeur une page que le moteur de publication ne peut pas servir, parce que les formes qui en produiraient une ne sont pas exprimables.
C'est une décision sur ce que le produit refuse de faire, prise avant que la moindre expérience d'édition existe, et c'est ce qui rend abordables les quatre choix ci-dessus. La parité de l'aperçu, une sortie déterministe et des migrations compatibles vers l'avenir sont chacune maîtrisables sur un ensemble borné de formes de documents, et chacune sans limite sur un ensemble non borné.
- L'alternative
- Un canevas libre : positionnement absolu, n'importe quel élément n'importe où. C'est la forme que vendent la plupart des outils de création et la première chose que demande un auteur. Il est réellement plus facile à construire, il fait meilleure impression dans les cinq premières minutes, et il n'impose aucune contrainte à la personne qui l'utilise.
- Ce que cela a coûté
- De l'expressivité, définitivement. Les mises en page qu'autorise un canevas libre ne sont pas accessibles ici, et pour certaines d'entre elles la réponse honnête est non plutôt qu'un contournement. La limite est aussi rencontrée en premier par les auteurs les plus disposés à pousser l'outil, qui sont les pires à décevoir.
- Pourquoi le compromis tient
- Sur un canevas libre, chaque document est un cas particulier : la parité de l'aperçu, le comportement adaptatif et la migration de schéma deviennent chacun un problème propre à chaque document, sans solution générale. Borner le modèle transforme trois problèmes sans limite en trois problèmes finis, et un problème fini peut être clos. Le coût est payé une fois, dans ce que l'outil ne fera pas. L'alternative facture indéfiniment, dans ce qu'elle ne peut pas promettre.
La comparaison ci-dessus est un argument sur les défaillances que chaque option rend possibles, pas un banc d'essai. Rien n'a été exécuté sur un jeu d'évaluation fixe : il n'y a donc aucun chiffre à rapporter ici, et rien de ce qui précède ne doit se lire comme en sous-entendant un.
Le raisonnement, publié.
Cette page décrit une classe de problème et non une mission pour un client. Voici les textes où le même raisonnement est développé en entier.
- ArticleConcevoir un système de design pensé d'abord pour le mode sombreCe dont une surface de création a besoin en dessous : des jetons porteurs de sens, pour qu'une page publiée et son éditeur ne puissent pas diverger.
- ArticleConcevoir des outils pour développeurs qui ne vous punissent pasLes valeurs par défaut, la divulgation progressive et les messages d'erreur : l'essentiel de ce qui sépare un outil de création utilisable d'un outil puissant dans lequel personne ne termine une page.
Interrogez-nous sur l'une ou l'autre de ces réalisations.
Les détails ne figurent pas sur cette page. Demandez-les directement, ou envoyez-nous le problème que vous avez réellement besoin de résoudre.