SaaS向けのFóir
プロダクトは1つのスキーマで多数の顧客にサービスを提供しており、作業の大半は顧客のデータを分けておくことです。Fóirではスキーマをあえて共有し、分離は自分で書くものではありません。
1つのスキーマ、変更する場所も1つ
マルチテナントでは、たいてい選択を迫られます。すべての顧客が一斉に移行しなければならない1つのスキーマか、1年後には誰も安全に変更できなくなる顧客ごとのフォークかです。
Fóirではモデルをプロジェクトに一度定義すると、その中のすべての顧客の組織がそれを継承します。顧客ごとのコピーではなく定義は1つなので、編集すればすべての顧客が提供する内容が変わります。顧客は、スキーマの残りをフォークすることなく、あなたのモデルの下に自分のモデルを定義できます。
共有スキーマは共有データではありません
許されない障害は、ある顧客が別の顧客の行を読むことです。多くのスタックでは、それを防ぐのは誰かが書き忘れなかった条件だけです。
各顧客はプロジェクト内の組織であり、書き込まれるすべての行にはデータベースでその組織が記録されます。アクセスは、どのコードパスが動いているかではなく、アプリケーションの下にあるPostgresによって強制されます。そのため、顧客を指定しないリクエストは、すべての行ではなく、その顧客の行を1つも返しません。データの新しい置き場所も、ルールが整うまでは出荷できません。コード内の読み取りや書き込みが顧客を指定することはありません。実行に使われる認証情報が決めるため、クエリを間違った顧客に向けることはできません。
顧客のセットアップはAPI呼び出し1回
顧客のサインアップは、たいていプロビジョニングのスクリプトを意味します。テナントを作り、ブランドを設定し、初期データを入れ、途中のステップが失敗するとその一部が残ります。
1回の呼び出しで、顧客に付けるIDをキーに、顧客をセットアップします。ブランディング付きの組織が作成され、設定の書き込み、最初のメンバーの追加、その顧客に限定されたキーの発行もできます。顧客はすぐにあなたのモデルを継承し、スキーマをコピーする必要はありません。同じIDでもう一度呼び出すと、2人目の顧客を作らず、完了しなかったステップから再開します。
最大の顧客が尋ねること
上位市場へ進むきっかけとなる案件にはセキュリティレビューが付いてきますが、誠実な答えは、たいてい意図を描いた図です。
ここでの分離は、ポリシーではなくデータベースの仕組みです。顧客のユーザーは、自社が所有するドメインで、あなたの名前ではなく自社の名前が入った画面からサインインします。そして顧客が自分のデータを求めた場合も、その組織として取ったエクスポートには、その顧客の行だけが含まれ、他の顧客の行は含まれません。すべての読み取りを制限するルールが、エクスポートも制限するからです。
すべての顧客が最初から持つもの
マルチテナント製品の部品のうち、本来は一度作って永遠に保守し続けることになるもの。
ユーザー向けのサインイン
登録、パスワード、ワンタイムコード、ソーシャル、OIDC。顧客が所有するドメインで提供されます。
顧客の名前を表示
組織ごとのロゴ、色、送信者名、サポート用アドレス。ユーザーが目にする画面とメールで使われます。
顧客ごとのキー
1社の顧客に限定したキーは、リクエストの内容にかかわらず、他の顧客へ向け直すことはできません。バックオフィスは1つのキーを保持し、リクエストごとに顧客を指定します。
アカウント内のロール
設定で宣言する顧客用ロール。権限システムを自作しなくても、顧客のチームに管理者とメンバーを置けます。
利用量の計測
顧客ごとに、オペレーションにローリングウィンドウでクォータを設け、所属するセグメントで制限できます。コンテンツのパーソナライズに使うものと同じオーディエンスを利用します。
同じ形の環境
1つの設定にステージングのプロジェクトと本番のプロジェクトを指定するので、スキーマの変更は顧客に届く前に安全な場所で試せます。
顧客ごとの利用状況
レコード、メディア、アクティブユーザー、メールを組織ごとに集計し、それぞれに設定可能な上限を持たせます。顧客ごとの利用量を確認し、制限できます。
バックグラウンド処理
組織ごとのオペレーション、スケジュール、イベントフック。リトライと、何が起きたかの記録付き。
メディア
変換とレスポンシブなレンディションを備えたアセットライブラリと、ファイルに対するアクセスルール。