OpenFeature Server SDK

The OpenFeature Server SDK is the Node.js implementation of the OpenFeature specification — a CNCF-hosted, vendor-neutral API for feature flag evaluation that decouples application code from any particular flag-management vendor. Instead of coding against LaunchDarkly’s SDK, Split’s SDK, or an in-house system directly, applications code against OpenFeature.getClient() and swap the underlying Provider implementation without touching call sites.

Beyond basic boolean/string/number/object flag evaluation, the SDK supports evaluation-context-based targeting, a hook lifecycle for cross-cutting concerns (logging, metrics, validation), domains for binding specific clients to specific providers, an eventing system for reacting to provider state changes, transaction-context propagation for request-scoped evaluation context, tracking for associating user actions with flag evaluations (useful for A/B testing), and a Multi-Provider that can combine several underlying providers with configurable evaluation strategies for migration, backup, or comparison scenarios.

What You Get

• OpenFeature.setProviderAndWait()/setProvider() to register a flag-management provider, plus OpenFeature.getClient() for typed boolean/string/number/object flag evaluation
• Evaluation-context-based targeting so flag decisions can vary by user, request, or transaction attributes
• A hook lifecycle (before/after/error/finally) for adding logging, metrics, or validation around every flag evaluation
• Domains to logically bind specific clients to specific providers within one application
• An eventing API to react to provider readiness, errors, and configuration changes
• A MultiProvider with pluggable evaluation strategies (first-match and others) for combining multiple providers during migrations or as a backup chain
• Tracking API to associate user actions with prior flag evaluations for experimentation/A-B testing analysis

Common Use Cases

• Adopting feature flags in a Node.js service without vendor lock-in, so the underlying flag provider can be swapped later with no code changes at call sites
• Migrating between feature-flag vendors gradually using MultiProvider, serving some flags from the old provider and some from the new one
• Adding cross-cutting flag-evaluation concerns (structured logging, metrics emission, context validation) once via hooks instead of at every call site
• Associating feature-flag exposure with downstream user actions for A/B test analysis via the tracking API

Under The Hood

Architecture: This is an Nx-managed monorepo (open-feature/js-sdk) with packages/server (the Node.js SDK), packages/web (browser SDK), packages/react and packages/angular (framework-specific distributions of the web SDK), packages/nest (a NestJS distribution of the server SDK), and packages/shared holding types and logic common to all of them (published separately as @openfeature/core, a required peer dependency). Inside packages/server/src, responsibilities are split across client/ (the per-domain Client implementation), provider/ (the provider interface and no-op/in-memory defaults), evaluation/, hooks/, events/, tracking/, and transaction-context/ — mirroring the OpenFeature spec’s own conceptual model rather than an ad-hoc internal structure. The top-level open-feature.ts implements the singleton OpenFeature global that wires provider registration to client creation.

Tech Stack: TypeScript throughout, built with esbuild for dual ESM/CJS output plus Rollup for bundled .d.ts type generation, targeting Node.js 18+ (the package.json declares >=20 engines in the latest release). @openfeature/core is a required peer dependency pinned to a specific compatible range per SDK version, since the shared spec types must stay in lockstep across server/web/react packages. Testing runs on Jest, and CI enforces coverage via Codecov, Snyk vulnerability scanning, and OpenSSF/CII Best Practices badging — signaling this is treated as security-sensitive infrastructure given its role in production flag evaluation.

Code Quality: The project carries CNCF-adjacent process rigor: a documented spec version compatibility contract (SDK versions map to specific openfeature/spec releases), OpenSSF Best Practices certification, and Snyk/Codecov badges in the README backing up test and vulnerability coverage claims. 45 contributors including bot-driven automated releases (release-please) indicate an actively governed, not single-maintainer, project. The clear package boundary between core (shared types) and server/web (environment-specific implementations) keeps environment-specific code from leaking into shared logic.

API Design: The primary developer-facing surface — setProviderAndWait, getClient, client.getBooleanValue(key, default) — mirrors the ergonomics of popular flag-vendor SDKs directly, so migrating an existing LaunchDarkly/Split integration to OpenFeature’s abstraction layer is a mechanical exercise rather than a conceptual one. More advanced features (hooks, domains, multi-provider, tracking) are additive and opt-in, so a minimal integration stays a two-line setProvider/getClient call while power users get a full lifecycle-hook and multi-provider system without added ceremony for the common case.