コンテンツにスキップ
FortressFlag Docs

flag がアプリに届くまで

あなたのアプリは、flag を確認するたびに FortressFlag を呼び出すわけではありません。flag の読み取りはローカルです。即時で、オフラインでも安全で、経路にネットワークはありません。ネットワークを流れるのは定期的なポーリングで、そのポーリングが何を取得するかは、2 つのプレーンのどちらにいるかで決まります。

クライアントプレーン：アプリはルールではなく答えを得る

Section titled “クライアントプレーン：アプリはルールではなく答えを得る”

iOS、Android、Web の SDK はクライアントプレーンを使います。デバイスは自分の ID とタグを送り、FortressFlag はターゲティングルールをサーバー側で評価して、そのデバイスの値だけを返します。{"new-checkout": true, "dark-mode": false} のような小さなマップです。

デバイスがあなたのルールを受け取ることはありません。これは二重の意味で意図的です。ターゲティングのロジック（「ベータコホート」「社内デバイス」）はあなたのビジネスであり、アプリのバイナリから誰でも取り出せるものの中に出荷されるべきではありません。そしてペイロードは小さいままです。

クライアントプレーンはクライアントキー（ffc_…）で認証します。これはアプリの中に入って出荷され、設計上公開されるものです。詳しくはキーで。

サーバープレーン：バックエンドは ruleset を得る

Section titled “サーバープレーン：バックエンドは ruleset を得る”

Go SDK はサーバープレーンを使います。サーバーは 1 つのプロジェクト + 環境の完全な ruleset（種類、デフォルト、ルール、セグメントは展開済み）をダウンロードし、flag を自身のプロセス内で評価します。flag の確認は、すでにメモリにあるデータへの関数呼び出しです。確認ごとのネットワーク往復も、リクエストごとのレイテンシもなく、1 回のポーリングが、いくつリクエストを処理していようとプロセス全体をまかないます。

ruleset にはターゲティングルールが含まれるため、このプレーンはサーバーキー（ffs_…）の背後にあります。データベースのパスワードと同じように扱う、正真正銘の秘密です。そしてあなたのルールはそのキーを持つすべてのサーバーに届くので、その帰結を適用するのはあなたです。ルールの条件に秘密やユーザーの個人データを入れないでください。

このプレーンにデバイス ID はありません。コードは評価ごとにコンテキストキー（ユーザー ID、セッション ID、何であれバケット分けの基準にするもの）を渡し、ロールアウトの算術はクライアントプレーンがデバイス ID を使うのとまったく同じようにそれを使います。だから同じ入力は、どちらのプレーンが評価しても同じコホートに入ります。

ポーリング、そしてそれが安い理由

Section titled “ポーリング、そしてそれが安い理由”

両プレーンとも一定間隔でポーリングし、両方とも条件付きリクエストを使います。各レスポンスはバリデーター（ETag）を運び、前回のポーリング以降に何も変わっていなければ、答えは小さな「変更なし」です。ボディも再評価もありません。flag を変更していないフリートの定常状態は、ほぼ無料の確認の連続です。

何かを変更したとき（切り替え、ルール、スケジュールの発火）は、次のポーリングがそれを完全な形で拾います。実際には、変更は約 1 分以内にオンラインのクライアントデバイスに届きます。

（課金に関する注記を 1 つ。「変更なし」のレスポンスも、月間アクティブデバイス数に対する活動として数えられます。ただし、デバイスはどれだけ頻繁にポーリングしても月に 1 回しか数えられないことを思い出してください。）

フォールバックの約束

Section titled “フォールバックの約束”

FortressFlag の障害が、あなたのアプリを止めることは決してあってはなりません。すべての SDK は最後に受け取った値を永続的なローカルキャッシュに保持し、同じカスケードで flag を解決します。

  1. 最後に受け取った値。前回の実行からのものも含みます。1 か月オフラインだったデバイスは、最後に見たものを配信します。想定外のリグレッションより、古さのほうが好ましいからです。
  2. コードのデフォルト。呼び出し箇所の値で、一度も何も受け取っていないときに使われます。（クライアント SDK は、デフォルトなしの boolean 読み取りでは false に行き着きます。）

知っておく価値のある帰結が 2 つあります。

  • 失効した、あるいは失敗する認証情報がアプリを壊すことはありません。SDK はキャッシュを配信し続け、再試行し続けます。エラーが flag の読み取りを通じてユーザーに届くことはありません。
  • SDK が検証できないペイロードは、ペイロードがまったくないものとして扱われます。すべてのレスポンスは署名されていて、SDK は何かが変わる前に署名を検証します。ペイロード署名を参照してください。
  • flag のアーカイブは本当にそれをオフにします。flag がペイロードから消えると、SDK は同じポーリングでそれをライブの値とキャッシュの両方から落とします。約 1 分以内に、あらゆる場所のオンラインデバイスがコードのデフォルトを解決します。キャッシュが削除された flag を保存し続けることはありません。もしそうなら、アーカイブでロールアウトを完全に終わらせることができなくなってしまいます。

次はどこへ

Section titled “次はどこへ”