OpenFeature

Co je feature flag?

V nejjednodušším případě je to if/else, který lze ovládat za běhu aplikace. Umožňuje měnit chování aplikace bez nasazení nového kódu.

if (client.getBooleanValue("new-checkout", false)) {
    renderNewCheckout();   // zapnuto za běhu, bez redeploye
} else {
    renderLegacyCheckout();
}

Flagy jsou dynamické (vyhodnocují se za běhu) a context-aware (rozhodnutí závisí např. na konkrétním uživateli).

K čemu jsou dobré?

Proč vznikl OpenFeature?

Jak to funguje

Vývojář pracuje pouze s Evaluation API. Provider mapuje volání na konkrétní flagging systém — vyměnitelný bez zásahu do aplikační logiky.

Evaluation API

Rozhraní, se kterým pracuje autor aplikace. Vyhodnocuje flagy a vrací typované hodnoty (boolean, string, number, object).

OpenFeatureAPI api = OpenFeatureAPI.getInstance();

// registrace poskytovatele (blokující, počká na READY)
api.setProviderAndWait(new YourProvider());

// získání klienta a vyhodnocení flagu
Client client = api.getClient();
boolean v2 = client.getBooleanValue("v2_enabled", false);

Druhý argument je default — hodnota při nedostupnosti provideru. Flag tedy nikdy „nespadne".

Providers

„Překladová vrstva" mezi Evaluation API a konkrétním flagging systémem. Mapuje argumenty na ekvivalent v daném systému.

• Může obalit SDK poskytovatele, volat REST API nebo číst lokální soubor
• Výměna provideru = změna jednoho řádku, aplikační kód beze změny
• Desítky hotových providerů — i vlastního snadno napíšete implementací rozhraní FeatureProvider stačí doplnit metody pro vyhodnocení jednotlivých typů (boolean, string, number, object)
• Multi-Provider — kombinace více poskytovatelů s konfigurovatelnou strategií
• flagd — referenční open-source provider/engine nativní podpora Kubernetes: flagy jako custom resource a automatická injekce sidecaru přes OpenFeature Operator

// migrace mezi providery bez zásahu do volání flagů
MultiProvider multi = new MultiProvider(
    List.of(newProvider, oldProvider)   // nový se ptá první
);
api.setProviderAndWait(multi);

Evaluation Context — vrstvení

Kontejner dat, na jejichž základě probíhá cílení. Skládá se ze čtyř vrstev, každá s jiným životním cyklem — od statických faktů o aplikaci po data jednoho requestu.

// 1) GLOBAL — statické, jednou při startu
api.setEvaluationContext(new ImmutableContext(Map.of(
    "region", new Value("eu-central-1"),
    "tier",   new Value("standard"))));  // výchozí

// 2) CLIENT — společné pro modul/doménu
Client checkout = api.getClient("checkout");
checkout.setEvaluationContext(new ImmutableContext(
    Map.of("module", new Value("checkout"))));

// 3) INVOCATION — data jednoho requestu
EvaluationContext req = new ImmutableContext(
    session.getId(),            // targetingKey
    Map.of("email",   new Value(email),
           "country", new Value("CZ")));
checkout.getBooleanValue("new-payment", false, req);

Hooks

Kód zapojený do životního cyklu vyhodnocení flagu. Registruje se ve třech úrovních (scope) — pozor, „client" = OpenFeature Client objekt, ne frontend.

// globálně — všechny klienty v procesu
api.addHooks(new LoggingHook());

// na klientovi — jeden Client (modul/doména)
Client checkout = api.getClient("checkout");
Client billing  = api.getClient("billing");
checkout.addHooks(new AuditHook());  // jen checkout

// jen pro jedno vyhodnocení
checkout.getBooleanValue("v2", false, ctx,
    FlagEvaluationOptions.builder()
        .hook(new ExampleHook()).build());

Slučování & obohacení

SDK vrstvy před vyhodnocením sloučí. Before hook doplní data, která nechceš tahat ručně u každého volání — typicky dotažená z jiné služby.

class EnrichmentHook implements Hook {
  public Optional<EvaluationContext> before(
      HookContext ctx, Map hints) {
    String userId = ctx.getCtx().getTargetingKey();
    String plan = subscriptions.lookupPlan(userId);
    return Optional.of(new ImmutableContext(
        Map.of("tier", new Value(plan))));  // "premium"
  }
}
api.addHooks(new EnrichmentHook());

{
  targetingKey: "<session-id>", // invocation
  region:       "eu-central-1", // global
  module:       "checkout",     // client
  email:        "...",          // invocation
  country:      "CZ",           // invocation
  tier:         "premium"       // hook přepsal
}

Pointa: statická data nastavíš jednou, proměnná předáš per request, odvozená zařídí hook — místo kopírování do každého volání. Flag pak cílí na kteroukoli vlastnost, např. tier=premium v region=eu-central-1.

Events

Reakce na změny stavu provideru nebo flagging systému — připravenost, chyby, nebo (nejzajímavěji) změna konfigurace flagů.

Client client = api.getClient();

// reakce na změnu konfigurace flagů
client.onProviderConfigurationChanged(e -> {
    // flagy se změnily v systému správy
});

// globální handler na zastarání cache provideru
api.onProviderStale(e -> { /* … */ });

Standardní události: PROVIDER_READY, PROVIDER_ERROR, PROVIDER_CONFIGURATION_CHANGED.

Flagy v testech

Pro testy nepotřebujete běžící flagging systém. SDK obsahuje In-Memory Provider — flagy definujete přímo v kódu a vyhodnocení běží lokálně, bez sítě.

Map<String, Flag<?>> flags = new HashMap<>();
flags.put("v2_enabled", Flag.builder()
    .variant("on", true)
    .variant("off", false)
    .defaultVariant("on").build());

api.setProviderAndWait(new InMemoryProvider(flags));

const flags = {
  v2_enabled: {
    variants: { on: true, off: false },
    disabled: false,
    defaultVariant: 'on',
  },
} as const;

OpenFeature.setProvider(new TypedInMemoryProvider(flags));

Varianty jsou pojmenované možné hodnoty flagu (on → true, off → false); defaultVariant určuje, která se vrátí bez targetingu. Jména jsou libovolná a flag nemusí být jen boolean — varianty mohou nést stringy či čísla.

Hodnoty lze měnit za běhu — ideální pro unit testy obou větví if/else. Pro jeden test stačí vyměnit provider, aplikační kód zůstává beze změny.

Server vs. client SDK

SDK přicházejí ve dvou variantách. Liší se hlavně v tom, jak modelují evaluation context.

// kontext při každém vyhodnocení
boolean v = client.getBooleanValue(
    "beta", false, reqCtx);

// kontext globálně (async), mění se zřídka
await OpenFeature.setContext({ targetingKey: userId });
// vyhodnocení je synchronní (z cache)
const v = client.getBooleanValue("beta", false);

Flagsmith na backendu

Local evaluation — stáhne definice flagů i segmenty a vyhodnocuje lokálně v procesu, bez sítě na každý flag.

Flagsmith na frontendu

Remote evaluation — stáhne jen vyhodnocené flagy pro klienta do cache (bez pravidel segmentů) a čte z ní synchronně.

Proč OpenFeature

• Jeden standard, žádná závislost na poskytovateli poskytovatele měníte bez zásahu do aplikačního kódu
• Konzistentní API napříč 10+ jazyky a frameworky
• Rozšiřitelnost přes hooks, providers a events
• Zaštítěno CNCF — neutrální, komunitní, otevřené Cloud Native Computing Foundation (nadace pod Linux Foundation) zastřešuje klíčové open-source projekty cloud-native světa — Kubernetes, Prometheus, Envoy a další.

Děkuji za pozornost — dotazy?