\n\n\n[OpenFeature](https://openfeature.dev) is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool or in-house solution.\n\n\n\n## 🚀 Quick start\n\n### Requirements\n\n- Node.js version 18+\n\n### Install\n\n#### npm\n\n```sh\nnpm install --save @openfeature/server-sdk\n```\n\n> [!TIP]\n> This SDK is designed to run in Node.JS. If you're interested in browser support, check out the [Web SDK](https://openfeature.dev/docs/reference/technologies/client/web/).\n\n#### yarn\n\n```sh\n# yarn requires manual installation of the @openfeature/core peer-dependency\nyarn add @openfeature/server-sdk @openfeature/core\n```\n\n> [!NOTE]\n> `@openfeature/core` contains common components used by all OpenFeature JavaScript implementations.\n> Every SDK version has a requirement on a single, specific version of this dependency.\n> For more information, and similar implications on libraries developed with OpenFeature see [considerations when extending](#considerations).\n\n### Usage\n\n```ts\nimport { OpenFeature } from '@openfeature/server-sdk';\n\n// Register your feature flag provider\ntry {\n await OpenFeature.setProviderAndWait(new YourProviderOfChoice());\n} catch (error) {\n console.error('Failed to initialize provider:', error);\n}\n\n// create a new client\nconst client = OpenFeature.getClient();\n\n// Evaluate your feature flag\nconst v2Enabled = await client.getBooleanValue('v2_enabled', false);\n\nif (v2Enabled) {\n console.log('v2 is enabled');\n}\n```\n\n### API Reference\n\nSee [here](https://open-feature.github.io/js-sdk/modules/_openfeature_server_sdk.html) for the complete API documentation.\n\n## 🌟 Features\n\n| Status | Features | Description |\n| ------ | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| ✅ | [Providers](#providers) | Integrate with a commercial, open source, or in-house feature management tool. |\n| ✅ | [Targeting](#targeting) | Contextually-aware flag evaluation using [evaluation context](https://openfeature.dev/docs/reference/concepts/evaluation-context). |\n| ✅ | [Hooks](#hooks) | Add functionality to various stages of the flag evaluation life-cycle. |\n| ✅ | [Logging](#logging) | Integrate with popular logging packages. |\n| ✅ | [Domains](#domains) | Logically bind clients with providers. |\n| ✅ | [Eventing](#eventing) | React to state changes in the provider or flag management system. |\n| ✅ | [Transaction Context Propagation](#transaction-context-propagation) | Set a specific [evaluation context](https://openfeature.dev/docs/reference/concepts/evaluation-context) for a transaction (e.g. an HTTP request or a thread) |\n| ✅ | [Tracking](#tracking) | Associate user actions with feature flag evaluations, particularly for A/B testing. |\n| ✅ | [Shutdown](#shutdown) | Gracefully clean up a provider during application shutdown. |\n| ✅ | [Extending](#extending) | Extend OpenFeature with custom providers and hooks. |\n| ✅ | [Multi-Provider](#multi-provider) | Combine multiple providers with configurable evaluation strategies. |\n\nImplemented: ✅ | In-progress: ⚠️ | Not implemented yet: ❌\n\n### Providers\n\n[Providers](https://openfeature.dev/docs/reference/concepts/provider) are an abstraction between a flag management system and the OpenFeature SDK.\nLook [here](https://openfeature.dev/ecosystem/?instant_search%5BrefinementList%5D%5Btype%5D%5B0%5D=Provider&instant_search%5BrefinementList%5D%5Bcategory%5D%5B0%5D=Server-side&instant_search%5BrefinementList%5D%5Btechnology%5D%5B0%5D=JavaScript) for a complete list of available providers.\nIf the provider you're looking for hasn't been created yet, see the [develop a provider](#develop-a-provider) section to learn how to build it yourself.\n\nOnce you've added a provider as a dependency, it can be registered with OpenFeature like this:\n\n#### Awaitable\n\nTo register a provider and ensure it is ready before further actions are taken, you can use the `setProviderAndWait` method as shown below:\n\n```ts\nawait OpenFeature.setProviderAndWait(new MyProvider());\n```\n\n#### Synchronous\n\nTo register a provider in a synchronous manner, you can use the `setProvider` method as shown below:\n\n```ts\nOpenFeature.setProvider(new MyProvider());\n```\n\nOnce the provider has been registered, the status can be tracked using [events](#eventing).\n\nIn some situations, it may be beneficial to register multiple providers in the same application.\nThis is possible using [domains](#domains), which is covered in more detail below.\n\n#### Multi-Provider\n\nThe Multi-Provider allows you to use multiple underlying providers as sources of flag data for the OpenFeature server SDK. When a flag is being evaluated, the Multi-Provider will consult each underlying provider it is managing in order to determine the final result. Different evaluation strategies can be defined to control which providers get evaluated and which result is used.\n\nThe Multi-Provider is a powerful tool for performing migrations between flag providers, or combining multiple providers into a single feature flagging interface. For example:\n\n- **Migration**: Gradually migrate from one provider to another by serving some flags from your old provider and some from your new provider\n- **Backup**: Use one provider as a backup for another in case of failures\n- **Comparison**: Compare results from multiple providers to validate consistency\n- **Hybrid**: Combine multiple providers to leverage different strengths (e.g., one for simple flags, another for complex targeting)\n\n```ts\nimport { OpenFeature, MultiProvider, FirstMatchStrategy } from '@openfeature/server-sdk';\n\n// Create providers\nconst primaryProvider = new YourPrimaryProvider();\nconst backupProvider = new YourBackupProvider();\n\n// Create multi-provider with a strategy\nconst multiProvider = new MultiProvider(\n [{ provider: primaryProvider }, { provider: backupProvider }],\n new FirstMatchStrategy(),\n);\n\n// Register the multi-provider\nawait OpenFeature.setProviderAndWait(multiProvider);\n\n// Use as normal\nconst client = OpenFeature.getClient();\nconst value = await client.getBooleanValue('my-flag', false);\n```\n\n**Available Strategies:**\n\n- `FirstMatchStrategy`: Returns the first successful result from the list of providers (short-circuits on error)\n- `FirstSuccessfulStrategy`: Returns the first successful result, ignoring errors from earlier providers\n- `ComparisonStrategy`: Compares results from multiple providers and can handle discrepancies\n\n**Migration Example:**\n\n```ts\nimport { OpenFeature, MultiProvider, FirstMatchStrategy } from '@openfeature/server-sdk';\n\n// During migration, serve some flags from the new provider and fallback to the old one\nconst newProvider = new NewFlagProvider();\nconst oldProvider = new OldFlagProvider();\n\nconst multiProvider = new MultiProvider(\n [{ provider: newProvider }, { provider: oldProvider }], // New provider is consulted first\n new FirstMatchStrategy(),\n);\n\nawait OpenFeature.setProviderAndWait(multiProvider);\n```\n\n**Comparison Example:**\n\n```ts\nimport { OpenFeature, MultiProvider, ComparisonStrategy } from '@openfeature/server-sdk';\n\n// Compare results from two providers for validation\nconst providerA = new ProviderA();\nconst providerB = new ProviderB();\n\nconst multiProvider = new MultiProvider(\n [{ provider: providerA }, { provider: providerB }],\n new ComparisonStrategy(providerA, (resolutions) => {\n console.warn('Mismatch detected', resolutions);\n }),\n);\n\nawait OpenFeature.setProviderAndWait(multiProvider);\n```\n\n### Targeting\n\nSometimes, the value of a flag must consider some dynamic criteria about the application or user, such as the user's location, IP, email address, or the server's location.\nIn OpenFeature, we refer to this as [targeting](https://openfeature.dev/specification/glossary#targeting).\nIf the flag management system you're using supports targeting, you can provide the input data using the [evaluation context](https://openfeature.dev/docs/reference/concepts/evaluation-context).\n\n```ts\n// set a value to the global context\nOpenFeature.setContext({ region: 'us-east-1' });\n\n// set a value to the client context\nconst client = OpenFeature.getClient();\nclient.setContext({ version: process.env.APP_VERSION });\n\n// set a value to the invocation context\nconst requestContext = {\n targetingKey: req.session.id,\n email: req.session.email,\n product: req.productId,\n};\n\nconst boolValue = await client.getBooleanValue('some-flag', false, requestContext);\n```\n\nContext is merged by the SDK before a flag evaluation occurs.\nThe merge order is defined [here](https://openfeature.dev/specification/sections/evaluation-context#requirement-323) in the OpenFeature specification.\n\n### Hooks\n\n[Hooks](https://openfeature.dev/docs/reference/concepts/hooks) allow for custom logic to be added at well-defined points of the flag evaluation life-cycle.\nLook [here](https://openfeature.dev/ecosystem/?instant_search%5BrefinementList%5D%5Btype%5D%5B0%5D=Hook&instant_search%5BrefinementList%5D%5Bcategory%5D%5B0%5D=Server-side&instant_search%5BrefinementList%5D%5Btechnology%5D%5B0%5D=JavaScript) for a complete list of available hooks.\nIf the hook you're looking for hasn't been created yet, see the [develop a hook](#develop-a-hook) section to learn how to build it yourself.\n\nOnce you've added a hook as a dependency, it can be registered at the global, client, or flag invocation level.\n\n```ts\nimport { OpenFeature } from '@openfeature/server-sdk';\n\n// add a hook globally, to run on all evaluations\nOpenFeature.addHooks(new ExampleGlobalHook());\n\n// add a hook on this client, to run on all evaluations made by this client\nconst client = OpenFeature.getClient();\nclient.addHooks(new ExampleClientHook());\n\n// add a hook for this evaluation only\nconst boolValue = await client.getBooleanValue('bool-flag', false, { hooks: [new ExampleHook()] });\n```\n\n### Logging\n\nThe Node.JS SDK will log warnings and errors to the console by default.\nThis behavior can be overridden by passing a custom logger either globally or per client.\nA custom logger must implement the [Logger interface](../shared/src/logger/logger.ts).\n\n```ts\nimport type { Logger } from '@openfeature/server-sdk';\n\n// The logger can be anything that conforms with the Logger interface\nconst logger: Logger = console;\n\n// Sets a global logger\nOpenFeature.setLogger(logger);\n\n// Sets a client logger\nconst client = OpenFeature.getClient();\nclient.setLogger(logger);\n```\n\n### Domains\n\nClients can be assigned to a domain.\nA domain is a logical identifier which can be used to associate clients with a particular provider.\nIf a domain has no associated provider, the default provider is used.\n\n```ts\nimport { OpenFeature, TypedInMemoryProvider } from '@openfeature/server-sdk';\n\nconst myFlags = {\n v2_enabled: {\n variants: {\n on: true,\n off: false,\n },\n disabled: false,\n defaultVariant: 'on',\n },\n} as const;\n\n// Registering the default provider\nOpenFeature.setProvider(new TypedInMemoryProvider(myFlags));\n// Registering a provider to a domain\nOpenFeature.setProvider('my-domain', new TypedInMemoryProvider(someOtherFlags));\n\n// A Client bound to the default provider\nconst clientWithDefault = OpenFeature.getClient();\n// A Client bound to the TypedInMemoryProvider provider\nconst domainScopedClient = OpenFeature.getClient('my-domain');\n```\n\nDomains can be defined on a provider during registration.\nFor more details, please refer to the [providers](#providers) section.\n\n### Eventing\n\nEvents allow you to react to state changes in the provider or underlying flag management system, such as flag definition changes, provider readiness, or error conditions.\nInitialization events (`PROVIDER_READY` on success, `PROVIDER_ERROR` on failure) are dispatched for every provider.\nSome providers support additional events, such as `PROVIDER_CONFIGURATION_CHANGED`.\n\nPlease refer to the documentation of the provider you're using to see what events are supported.\n\n```ts\nimport { OpenFeature, ProviderEvents } from '@openfeature/server-sdk';\n\n// OpenFeature API\nOpenFeature.addHandler(ProviderEvents.Ready, (eventDetails) => {\n console.log(`Ready event from: ${eventDetails?.providerName}:`, eventDetails);\n});\n\n// Specific client\nconst client = OpenFeature.getClient();\nclient.addHandler(ProviderEvents.Error, (eventDetails) => {\n console.log(`Error event from: ${eventDetails?.providerName}:`, eventDetails);\n});\n```\n\n### Transaction Context Propagation\n\nTransaction context is a container for transaction-specific evaluation context (e.g. user id, user agent, IP).\nTransaction context can be set where specific data is available (e.g. an auth service or request handler) and by using the transaction context propagator it will automatically be applied to all flag evaluations within a transaction (e.g. a request or thread).\n\nThe following example shows an Express middleware using transaction context propagation to propagate the request ip and user id into request scoped transaction context.\n\n```ts\nimport express, { Request, Response, NextFunction } from 'express';\nimport { OpenFeature, AsyncLocalStorageTransactionContextPropagator } from '@openfeature/server-sdk';\n\nOpenFeature.setTransactionContextPropagator(new AsyncLocalStorageTransactionContextPropagator());\n\n/**\n * This example is based on an express middleware.\n */\nconst app = express();\napp.use((req: Request, res: Response, next: NextFunction) => {\n const ip = req.headers['x-forwarded-for'];\n OpenFeature.setTransactionContext({ targetingKey: req.user.id, ipAddress: ip }, () => {\n // The transaction context is used in any flag evaluation throughout the whole call chain of next\n next();\n });\n});\n```\n\n### Tracking\n\nThe tracking API allows you to use OpenFeature abstractions and objects to associate user actions with feature flag evaluations.\nThis is essential for robust experimentation powered by feature flags.\nFor example, a flag enhancing the appearance of a UI component might drive user engagement to a new feature; to test this hypothesis, telemetry collected by a [hook](#hooks) or [provider](#providers) can be associated with telemetry reported in the client's `track` function.\n\n```ts\n// flag is evaluated\nawait client.getBooleanValue('new-feature', false);\n\n// new feature is used and track function is called recording the usage\nuseNewFeature();\nclient.track('new-feature-used');\n```\n\n### Shutdown\n\nThe OpenFeature API provides a close function to perform a cleanup of all registered providers.\nThis should only be called when your application is in the process of shutting down.\n\n```ts\nimport { OpenFeature } from '@openfeature/server-sdk';\n\nawait OpenFeature.close();\n```\n\n### Type-Safe Flag Keys\n\nFor enhanced type safety and autocompletion, you can override flag key types using TypeScript module augmentation. See the [`@openfeature/core` README](../shared/README.md#type-safe-flag-keys) for details.\n\n## Extending\n\n### Develop a provider\n\nTo develop a provider, you need to create a new project and include the OpenFeature SDK as a dependency.\nThis can be a new repository or included in [the existing contrib repository](https://github.com/open-feature/js-sdk-contrib) available under the OpenFeature organization.\nYou’ll then need to write the provider by implementing the [Provider interface](./src/provider/provider.ts) exported by the OpenFeature SDK.\n\n```ts\nimport {\n AnyProviderEvent,\n EvaluationContext,\n Hook,\n JsonValue,\n Logger,\n Provider,\n ProviderEventEmitter,\n ResolutionDetails,\n} from '@openfeature/server-sdk';\n\n// implement the provider interface\nclass MyProvider implements Provider {\n // Adds runtime validation that the provider is used with the expected SDK\n public readonly runsOn = 'server';\n readonly metadata = {\n name: 'My Provider',\n } as const;\n // Optional provider managed hooks\n hooks?: Hook[];\n resolveBooleanEvaluation(\n flagKey: string,\n defaultValue: boolean,\n context: EvaluationContext,\n logger: Logger,\n ): Promise> {\n // code to evaluate a boolean\n }\n resolveStringEvaluation(\n flagKey: string,\n defaultValue: string,\n context: EvaluationContext,\n logger: Logger,\n ): Promise> {\n // code to evaluate a string\n }\n resolveNumberEvaluation(\n flagKey: string,\n defaultValue: number,\n context: EvaluationContext,\n logger: Logger,\n ): Promise> {\n // code to evaluate a number\n }\n resolveObjectEvaluation(\n flagKey: string,\n defaultValue: T,\n context: EvaluationContext,\n logger: Logger,\n ): Promise> {\n // code to evaluate an object\n }\n\n // implement with \"new OpenFeatureEventEmitter()\", and use \"emit()\" to emit events\n events?: ProviderEventEmitter | undefined;\n\n initialize?(context?: EvaluationContext | undefined): Promise {\n // code to initialize your provider\n }\n onClose?(): Promise {\n // code to shut down your provider\n }\n}\n```\n\n> Built a new provider? [Let us know](https://github.com/open-feature/openfeature.dev/issues/new?assignees=&labels=provider&projects=&template=document-provider.yaml&title=%5BProvider%5D%3A+) so we can add it to the docs!\n\n### Develop a hook\n\nTo develop a hook, you need to create a new project and include the OpenFeature SDK as a dependency.\nThis can be a new repository or included in [the existing contrib repository](https://github.com/open-feature/js-sdk-contrib) available under the OpenFeature organization.\nImplement your own hook by conforming to the [Hook interface](../shared/src/hooks/hook.ts).\n\n```ts\nimport type { Hook, HookContext, EvaluationDetails, FlagValue } from '@openfeature/server-sdk';\n\nexport class MyHook implements Hook {\n after(hookContext: HookContext, evaluationDetails: EvaluationDetails) {\n // code that runs after flag values are successfully resolved from the provider\n }\n}\n```\n\n> Built a new hook? [Let us know](https://github.com/open-feature/openfeature.dev/issues/new?assignees=&labels=hook&projects=&template=document-hook.yaml&title=%5BHook%5D%3A+) so we can add it to the docs!\n\n### Considerations\n\nWhen developing a library based on OpenFeature components, it's important to list the `@openfeature/server-sdk` as a `peerDependency` of your package.\nThis is a general best-practice when developing JavaScript libraries that have dependencies in common with their consuming application.\nFailing to do this can result in multiple copies of the OpenFeature SDK in the consumer, which can lead to type errors, and broken singleton behavior.\nThe `@openfeature/core` package itself follows this pattern: the `@openfeature/server-sdk` has a peer dependency on `@openfeature/core`, and uses whatever copy of that module the consumer has installed (note that NPM installs peers automatically unless `--legacy-peer-deps` is set, while yarn does not, and PNPM does so based on its configuration).\nWhen developing such libraries, it's NOT necessary to add a `peerDependency` on `@openfeature/core`, since the `@openfeature/server-sdk` establishes that dependency itself transitively.\n","readmeFilename":"README.md"}
![\"OpenFeature](\"https://raw.githubusercontent.com/open-feature/community/0e23508c163a6a1ac8c0ced3e4bd78faafe627c7/assets/logo/horizontal/white/openfeature-horizontal-white.svg\"){kind=logo}
\n ![\"Specification\"](\"https://img.shields.io/static/v1?label=specification&message=v0.8.0&color=yellow&style=for-the-badge\")
![\"Release\"](\"https://img.shields.io/static/v1?label=release&message=v1.23.0&color=blue&style=for-the-badge\")
![\"API](\"https://img.shields.io/badge/reference-teal?logo=javascript&logoColor=white\"){kind=icon}
![\"NPM](\"https://img.shields.io/npm/dm/%40openfeature%2Fserver-sdk\")
![\"codecov\"](\"https://codecov.io/gh/open-feature/js-sdk/branch/main/graph/badge.svg?token=3DC5XOEHMY\"){kind=icon}
\n \n \n