Skip to content

CONCEPT Cited by 1 source

Vendor-neutral evaluation API

A vendor-neutral evaluation API standardises the call surface developers use to invoke a pluggable capability (flag evaluation, tracing, model inference, …) so that the application code does not depend on the specific provider implementation underneath. Swapping providers is a configuration change, not a rewrite of every call site.

The template: define the API as an open standard, let each backend plug in behind a Provider interface.

The OpenTelemetry / OpenFeature analogy

OpenFeature is to feature flags what OpenTelemetry is to observability. The Cloudflare Flagship launch post makes the analogy explicit:

"OpenFeature defines a common interface for flag evaluation across languages and providers — it's the same relationship that OpenTelemetry has to observability. You write your evaluation code once against the standard, and swap providers by changing a single line of configuration."

Both projects are CNCF-hosted, both target the same structural problem — the switching-cost asymmetry that otherwise locks a team into the first vendor they adopted.

Why the shape matters

Without a vendor-neutral API:

  • Adoption burns a provider-specific call shape into every site that uses the capability.
  • Migration requires touching every call site — prohibitive past a few hundred usages.
  • Competitive pressure on the provider disappears; customer switching cost is the provider's moat.

With it:

  • Call sites import from the standard (@openfeature/server- sdk); the provider is installed once at startup (OpenFeature.setProviderAndWait(new FlagshipServerProvider( …))).
  • Migration is a one-line swap at the startup point.
  • Providers compete on the provider-side implementation (latency, rule richness, audit trail, price) rather than on lock-in.

Flagship's marketing is unusually direct about this inversion:

"Adopt Flagship without rewriting your evaluation code. Leave without rewriting it either."

This is only credible because the call surface is the standard's, not Flagship's.

Shape of the API

OpenFeature's call surface, as used by Flagship (from the launch post):

import { OpenFeature } from '@openfeature/server-sdk';
import { FlagshipServerProvider } from '@cloudflare/flagship/server';

await OpenFeature.setProviderAndWait(
  new FlagshipServerProvider({ /* provider config */ })
);

const client = OpenFeature.getClient();
const showNewCheckout = await client.getBooleanValue(
  'new-checkout-flow',
  false,
  { targetingKey: 'user-42', plan: 'enterprise', country: 'US' }
);
  • OpenFeature.setProviderAndWait(...) — install once.
  • client.getBooleanValue(key, default, context) and the typed siblings for string/number/object — identical shape regardless of provider.

Caveat — the "one line of config" claim

The post's framing — "swap providers by changing a single line of configuration" — is true at the API-call-site tier but not quite at the system tier. In practice, rule schemas, context-attribute conventions, rollout-hash algorithms, and audit-trail formats can differ across backends; you may still need to re-author flags on the new provider even if the evaluation call surface is stable. The standard gives you call-site portability, which is the expensive half, not zero-config migration.

Sibling patterns

Seen in

Last updated · 200 distilled / 1,178 read