Fóir für SaaS
Ihr Produkt ist ein Schema, das viele Kunden bedient, und der größte Teil der Arbeit besteht darin, deren Daten getrennt zu halten. In Fóir ist das Schema bewusst gemeinsam, und die Isolation müssen Sie nicht schreiben.
Ein Schema und eine Stelle, es zu ändern
Multi-Tenancy zwingt meist zu einer Wahl: ein Schema, mit dem jeder Kunde gleichzeitig umziehen muss, oder ein Fork pro Kunde, den ein Jahr später niemand mehr sicher ändern kann.
In Fóir wird ein Modell einmal in Ihrem Projekt definiert, und die Organisation jedes Kunden darin erbt es. Es gibt eine Definition statt einer Kopie pro Kunde, sodass eine Änderung das ändert, was alle ausliefern. Ein Kunde kann unterhalb Ihres Modells ein eigenes definieren, ohne den Rest Ihres Schemas zu forken.
Ein gemeinsames Schema heißt nicht gemeinsame Daten
Der Fehler, den Sie sich nicht leisten können, ist ein Kunde, der die Zeilen eines anderen liest, und in den meisten Stacks steht dem nur eine Klausel im Weg, an die jemand beim Schreiben gedacht hat.
Jeder Kunde ist eine Organisation in Ihrem Projekt, und jede Zeile, die er schreibt, wird in der Datenbank damit gekennzeichnet. Der Zugriff wird von Postgres unterhalb Ihrer Anwendung durchgesetzt und nicht von dem Codepfad, der gerade läuft. Eine Anfrage, die keinen Kunden nennt, liefert deshalb keine seiner Zeilen zurück statt aller, und ein neuer Ort für Daten kann nicht ohne abdeckende Regeln ausgeliefert werden. Kein Lese- oder Schreibzugriff in Ihrem Code nennt den Kunden. Die Zugangsdaten, unter denen er läuft, entscheiden, sodass eine Abfrage nicht auf den falschen gerichtet werden kann.
Einen Kunden einzurichten ist ein API-Aufruf
Einen Kunden anzumelden bedeutet meist ein Bereitstellungsskript, das einen Tenant anlegt, ihm ein Branding gibt, ihn befüllt und die Hälfte davon zurücklässt, wenn ein Schritt fehlschlägt.
Ein Aufruf richtet den Kunden ein, mit einer ID, die Sie für ihn wählen. Er legt dessen Organisation samt Branding an und kann seine Einstellungen schreiben, sein erstes Mitglied hinzufügen und einen Schlüssel erzeugen, der auf ihn beschränkt ist. Er erbt Ihre Modelle sofort, ohne dass ein Schema an Ort und Stelle kopiert werden muss. Wird der Aufruf mit derselben ID wiederholt, setzt er bei dem Schritt fort, der nicht abgeschlossen wurde, statt einen zweiten Kunden anzulegen.
Was Ihr größter Kunde fragen wird
Der Abschluss, der Sie in einen anspruchsvolleren Markt bringt, kommt mit einer Sicherheitsprüfung, und die ehrliche Antwort ist meist ein Diagramm voller Absichten.
Isolation ist hier ein Datenbankmechanismus und keine Richtlinie. Seine Nutzer melden sich auf einer Domain an, die ihm gehört, auf Bildschirmen mit seinem Namen statt Ihrem. Und wenn er jemals seine Daten verlangt, enthält ein Export, der als seine Organisation erstellt wird, seine Zeilen und keine eines anderen Kunden, denn die Regel, die jeden Lesezugriff einschränkt, schränkt auch den Export ein.
Womit jeder Kunde startet
Die Teile eines mandantenfähigen Produkts, die Sie sonst einmal bauen und für immer pflegen würden.
Anmeldung für deren Nutzer
Registrierung, Passwort, Einmalcode, Social und OIDC, auf einer Domain, die dem Kunden gehört.
Ihr Name darauf
Logo, Farbe, Absendername und Support-Adresse pro Organisation, verwendet von den Bildschirmen und E-Mails, die deren Nutzer sehen.
Ein Schlüssel pro Kunde
Ein Schlüssel, der auf einen Kunden beschränkt ist, lässt sich nirgendwo anders hinlenken, was auch immer die Anfrage sagt. Ihr Back-Office hält einen Schlüssel und nennt den Kunden pro Anfrage.
Rollen innerhalb ihres Kontos
Kundenrollen, die Sie in der Config deklarieren, damit das Team Ihres Kunden Admins und Mitglieder hat, ohne dass Sie ein Berechtigungssystem bauen.
Nutzung messen
Begrenzen Sie eine Operation pro Kunde in einem gleitenden Zeitfenster per Kontingent und steuern Sie sie über das Segment, in dem der Kunde sich befindet, mit denselben Zielgruppen, die auch seine Inhalte personalisieren.
Umgebungen in derselben Form
Eine Config benennt ein Staging-Projekt und ein Produktionsprojekt, sodass eine Schemaänderung an einem sicheren Ort erprobt wird, bevor sie Kunden erreicht.
Nutzung pro Kunde
Datensätze, Medien, aktive Nutzer und E-Mails werden pro Organisation gezählt, jeweils mit einer Obergrenze, die Sie festlegen können, sodass Sie sehen und begrenzen können, was jeder Kunde nutzt.
Hintergrundarbeit
Operations, Zeitpläne und Event-Hooks pro Organisation, mit Wiederholungen und einem Protokoll dessen, was geschehen ist.
Medien
Eine Asset-Bibliothek mit Transformationen und responsiven Renditions sowie Zugriffsregeln für Dateien.
Einmal modellieren, dann den zweiten Kunden hinzufügen
Legen Sie ein Projekt an und übertragen Sie die Modelle, auf denen Ihr Produkt läuft. Der nächste Kunde ist eine Organisation darin.