コンテンツにスキップ

Java クイックスタート

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

依存はゼロ。JSON も含めてです。SDK は独自の小さなパーサーを内蔵しているので、依存ツリーに新しいものは何も入りません。Java 17 以降で動きます。

SDK は GitHub の公開リポジトリにあります。リリースタグでクローンしてビルドし、あなたのビルドに含めてください。たとえば Gradle の included build として、あるいは jar を社内リポジトリに公開して。

Terminal window
git clone --branch v1.0.0 https://github.com/FortressFlag/FortressFlag_SDK_java
cd FortressFlag_SDK_java && ./gradlew build

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

Section titled “2. サーバーキー、正真正銘の秘密”

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

import com.fortressflag.server.Client;
import com.fortressflag.server.Configuration;
import com.fortressflag.server.FortressFlag;
import java.time.Duration;
Client client = FortressFlag.create(
Configuration.builder(System.getenv("FF_SERVER_KEY")).build());
// ^ SDK が例外を投げる唯一の場所:何かを配信する前の、不正なキー。
client.start(Duration.ofSeconds(15)); // 最初の ruleset(または期限)で戻る
// ... サービスが動く。flag の確認はもうメモリ内のメソッド呼び出し。

start が例外を投げることはありません。最初の取得が時間内に届かなければ、クライアントはバックグラウンドスレッドで再試行を続け、その間、呼び出し元はフォールバックを受け取ります。ポーラーはデーモンスレッドで動き、JVM の終了を妨げることはありません。

import com.fortressflag.server.Context;
import java.util.Map;
boolean enabled = client.boolValue(
"new-checkout",
new Context(
"user-42", // 安定したコンテキストキー:ユーザー ID、セッション ID など、あなたの選択
Map.of("cohort", "beta")),
false); // flag が不明、または一度も取得していないときのフォールバック

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

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

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