ベストプラクティス

次のパターンで、Flagship の評価を予測しやすく、高速で、保守しやすく保ちます。

Cloudflare Workers 内では Workers バインディング を使います。バインディングは認証を自動で処理し、アプリケーション側で API トークンを管理する必要がありません。

Workers の外で動かす場合や、ベンダー非依存の OpenFeature インターフェイスが必要なときは、OpenFeature SDK を使います。Workers 内でも、バインディングを OpenFeature のサーバープロバイダーに渡せます。バインディングの性能を保ったまま、OpenFeature API を使えます。

同じフラグをループ内で何度も評価しないでください。フラグは 1 回評価し、結果をローカル変数に保存して、そのリクエスト中は再利用します。

const enabled = await env.FLAGS.getBooleanValue("show-related-items", false, {
	userId,
});

for (const item of items) {
	if (enabled) {
		item.related = await loadRelatedItems(item.id);
	}
}

ターゲティングとパーセンテージロールアウトは、アプリケーションから渡す評価コンテキストに依存します。安定した識別子と、同じ属性名をどこでも使ってください。

const context = {
	userId: session.user.id,
	plan: session.user.plan,
	country: request.cf?.country ?? "unknown",
};

const enabled = await env.FLAGS.getBooleanValue("new-checkout", false, context);

OpenFeature SDK では、安定した識別子として targetingKey を使います。Workers バインディングでは、ロールアウトに設定した属性（userId など）を使います。

どの評価メソッドにもデフォルト値が必要です。フラグが存在しない、評価できない、型が一致しない場合でも、アプリケーションが安全なままになる値を選んでください。

リリース用フラグでは、通常は既存の体験をデフォルトにします。設定用フラグでは、追加の依存関係なしでアプリケーションが扱える、控えめな上限や動作を選んでください。

値が返された理由を知りたいときは、*Details メソッドを使います。details には、解決された値、バリアント、reason、エラーのメタデータが含まれます。

const details = await env.FLAGS.getBooleanDetails("new-checkout", false, {
	userId: "user-42",
});

console.log(details.value);
console.log(details.variant);
console.log(details.reason);
console.log(details.errorCode);

小さなパーセンテージロールアウトから始め、アプリケーションの指標を監視し、その後パーセンテージを上げていきます。

1. 5% など、小さなロールアウトでフラグを作成します。
2. エラー、レイテンシ、ビジネス指標、ユーザーからのフィードバックを監視します。
3. 信頼が高まったら、25%、50%、100% と上げます。
4. ロールアウトが 100% に達したら、採用したバリアントをデフォルトにし、一時的なターゲティングルールを削除します。
5. 機能を完全に出荷したら、古いコードパスを削除し、フラグを削除します。

無効化したフラグや、完全にロールアウト済みのフラグも、保守コストがかかります。フラグを削除する前に、まず無効化し、想定外の動作がないか監視し、評価コードを削除してデプロイしてから、Flagship 上のフラグを削除します。