Fóir pour le SaaS
Votre produit est un seul schéma au service de nombreux clients, et l'essentiel du travail consiste à garder leurs données séparées. Dans Fóir, le schéma est partagé volontairement, et l'isolation n'est pas quelque chose que vous écrivez.
Un schéma, et un seul endroit pour le modifier
La multi-tenancy impose en général un choix : un schéma que tous les clients doivent suivre en même temps, ou un fork par client que personne ne peut modifier sans risque un an plus tard.
Dans Fóir, un modèle est défini une fois, sur votre projet, et l'organisation de chaque client à l'intérieur l'hérite. Il y a une seule définition plutôt qu'une copie par client : la modifier change ce que tous servent. Un client peut définir un modèle qui lui est propre sous le vôtre sans forker le reste de votre schéma.
Un schéma partagé n'est pas des données partagées
La défaillance que vous ne pouvez pas vous permettre est qu'un client lise les lignes d'un autre, et dans la plupart des stacks, la seule chose qui l'empêche est une clause que quelqu'un a pensé à écrire.
Chaque client est une organisation dans votre projet, et chaque ligne qu'il écrit est estampillée avec elle dans la base de données. L'accès est appliqué par Postgres sous votre application plutôt que par le chemin de code qui s'exécute : une requête qui ne désigne aucun client ne renvoie aucune de leurs lignes plutôt que toutes, et un nouvel endroit où placer des données ne peut pas être livré sans règles qui le couvrent. Aucune lecture ni écriture dans votre code ne nomme le client. C'est le identifiant avec lequel elle s'exécute qui décide, de sorte qu'une requête ne peut pas être dirigée vers le mauvais.
Mettre un client en place est un appel d'API
Inscrire un client signifie en général un script de provisionnement qui crée un tenant, lui applique son identité de marque, l'alimente, et en laisse la moitié en plan quand une étape échoue.
Un seul appel met le client en place, identifié par un id que vous choisissez pour lui. Il crée son organisation avec son identité de marque, et peut écrire ses paramètres, ajouter son premier membre et émettre une clé qui lui est confinée. Il hérite immédiatement de vos modèles, sans schéma à copier en place. Rappelez l'appel avec le même id et il reprend à l'étape qui ne s'est pas terminée au lieu de créer un second client.
Ce que demandera votre plus gros client
Le contrat qui vous fait monter en gamme arrive avec une revue de sécurité, et la réponse honnête est le plus souvent un schéma d'intentions.
L'isolation est ici un mécanisme de base de données plutôt qu'une politique. Ses utilisateurs se connectent sur un domaine qui lui appartient, sur des écrans qui portent son nom plutôt que le vôtre. Et s'il demande un jour ses données, un export réalisé comme son organisation contient ses lignes et celles d'aucun autre client, parce que la règle qui confine chaque lecture confine aussi l'export.
Ce que chaque client reçoit au départ
Les éléments d'un produit multi-tenant que vous construiriez autrement une fois et maintiendriez pour toujours.
La connexion de leurs utilisateurs
Inscription, mot de passe, code à usage unique, social et OIDC, sur un domaine que le client possède.
Leur nom dessus
Logo, couleur, nom d'expéditeur et adresse d'assistance par organisation, utilisés par les écrans et les e-mails que voient leurs utilisateurs.
Une clé par client
Une clé confinée à un client ne peut être dirigée nulle part ailleurs, quoi que dise la requête. Votre back-office détient une seule clé et nomme le client à chaque requête.
Des rôles dans leur compte
Des rôles clients que vous déclarez dans la config, de sorte que l'équipe de votre client ait des administrateurs et des membres sans que vous construisiez un système de permissions.
Mesurer ce qu'ils utilisent
Appliquez un quota à une opération par client sur une fenêtre glissante, et conditionnez-la au segment auquel il appartient, avec les mêmes audiences que celles qui personnalisent son contenu.
Des environnements de même forme
Une seule config nomme un projet de staging et un projet de production, si bien qu'un changement de schéma est répété dans un endroit sûr avant d'atteindre les clients.
L'usage par client
Enregistrements, médias, utilisateurs actifs et e-mails comptés par organisation, chacun avec un plafond que vous pouvez fixer, afin de voir et de limiter ce que chaque client utilise.
Le travail en arrière-plan
Opérations, planifications et hooks d'événements par organisation, avec des relances et une trace de ce qui s'est passé.
Médias
Une bibliothèque de médias avec transformations et rendus adaptatifs, et des règles d'accès sur les fichiers.
Le modéliser une fois, puis ajouter le deuxième client
Créez un projet et poussez les modèles sur lesquels votre produit fonctionne. Le client suivant est une organisation à l'intérieur.