Node.js クイックスタート

数分で、あなたの Node サービスはフィーチャーフラグをプロセス内で評価するようになります。確認ごとのネットワーク往復も、リクエスト経路のレイテンシもなく、1 回のポーリングがプロセスの処理するすべてのリクエストをまかないます。

ランタイム依存はゼロ。パッケージの dependencies ブロックは存在せず、これからも存在しません。

1. インストール

SDK は GitHub の公開リポジトリにあります。そこから直接、リリースに固定してインストールしてください。

npm install github:FortressFlag/FortressFlag_SDK_node#v1.0.0

#v1.0.0 を省くと、代わりに development ブランチを追うことになります。修正を試すには便利ですが、本番で望むものではありません。

パッケージは ESM 専用です。Node 22 以降では、CommonJS のコードからもプレーンな require("@fortressflag/sdk-node") で読み込めます。

2. サーバーキー、正真正銘の秘密

この SDK はサーバーキー（ffs_…）を使います。モバイルや Web の SDK が出荷するクライアントキーとは正反対で、ターゲティングルールを含む完全な ruleset をダウンロードできます。データベースのパスワードとまったく同じように扱ってください。環境変数かシークレットマネージャーに置き、コード、リポジトリ、ログには決して入れません。2 つのキーのクラスを並べて。

3. クライアントを起動する

import { create } from "@fortressflag/sdk-node";

let client;
try {
  client = create({ key: process.env.FF_SERVER_KEY });
} catch (error) {
  // SDK が例外を投げる唯一の場所：何かを配信する前の、不正なキー。
  console.error(error);
  process.exit(1);
}

await client.start(AbortSignal.timeout(15_000)); // 最初の ruleset（または期限）で解決する

// ... サービスが動く。flag の確認はもうメモリ内の関数呼び出し。

start が reject されることはありません。最初の取得が時間内に届かなければ、クライアントはバックグラウンドで再試行を続け、その間、呼び出し元はフォールバックを受け取ります。そしてポーラーがプロセスを生かし続けることはありません。コードが終われば、Node はいつもどおり終了します。

4. flag を評価する

const enabled = client.bool(
  "new-checkout",
  {
    key: "user-42", // 安定したコンテキストキー：ユーザー ID、セッション ID など、あなたの選択
    tags: { cohort: "beta" },
  },
  false, // flag が不明、または一度も取得していないときのフォールバック
);

client.string と client.number も同じように動きます。コンテキストの key はパーセンテージロールアウトがバケット分けの基準にするものです。同じ識別子を一貫して渡せば、各ユーザーは安定したコホートを得ます。それはあなたのデータです。SDK が検証、保存、ログすることは決してありません。

これで完了です。サービスはローカルで flag を評価しています。ダッシュボードの変更は約 1 分以内にすべてのプロセスに届きます。

評価は決して失敗しない

bool、string、number は常に答え、決して例外を投げません。flag の問題がサービスを止めることがあってはならないからです。再起動したプロセスは、最初の取得が届くまで呼び出し箇所のフォールバックを配信します（あるいは設定で cachePath を指定して、最後の ruleset を任意のファイルに永続化すれば、再起動はそこから即座に再開します）。失効したキーでさえ何も壊しません。SDK は、新しいキーを渡すまで、最後にダウンロードした ruleset で評価を続けます。

次はどこへ

flag がアプリに届くまで：サーバープレーンの解説
キー：ffs_ キーの発行、ローテーション、失効
ターゲティング：サービスがいま評価しているルール