npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@openfeature/multi-provider-web

v0.0.2

Published

The Multi-Provider allows you to use multiple underlying providers as sources of flag data for the OpenFeature web SDK. When a flag is being evaluated, the Multi-Provider will consult each underlying provider it is managing in order to determine the final

Downloads

747

Readme

OpenFeature Multi-Provider

The Multi-Provider allows you to use multiple underlying providers as sources of flag data for the OpenFeature web 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.

The Multi-Provider is a powerful tool for performing migrations between flag providers, or combining multiple providers into a single feature flagging interface. For example:

  • Migration: When migrating between two providers, you can run both in parallel under a unified flagging interface. As flags are added to the new provider, the Multi-Provider will automatically find and return them, falling back to the old provider if the new provider does not have
  • Multiple Data Sources: The Multi-Provider allows you to seamlessly combine many sources of flagging data, such as environment variables, local files, database values and SaaS hosted feature management systems.

Installation

$ npm install @openfeature/multi-provider-web

[!TIP] This provider is designed to be used with the Web SDK.

Usage

The Multi-Provider is initialized with an array of providers it should evaluate:

import { WebMultiProvider } from '@openfeature/multi-provider-web'
import { OpenFeature } from '@openfeature/web-sdk'

const multiProvider = new WebMultiProvider([
  {
      provider: new ProviderA()
  },
  {
      provider: new ProviderB()
  }
])

await OpenFeature.setProviderAndWait(multiProvider)

const client = OpenFeature.getClient()

console.log("Evaluating flag")
console.log(client.getBooleanDetails("my-flag", false));

By default, the Multi-Provider will evaluate all underlying providers in order and return the first successful result. If a provider indicates it does not have a flag (FLAG_NOT_FOUND error code), then it will be skipped and the next provider will be evaluated. If any provider throws or returns an error result, the operation will fail and the error will be thrown. If no provider returns a successful result, the operation will fail with a FLAG_NOT_FOUND error code.

To change this behaviour, a different "strategy" can be provided:

import { WebMultiProvider, FirstSuccessfulStrategy } from '@openfeature/multi-provider-web'

const multiProvider = new WebMultiProvider(
    [
      {
        provider: new ProviderA()
      },
      {
        provider: new ProviderB()
      }
    ], 
    new FirstSuccessfulStrategy()
)

The Multi-Provider comes with three strategies out of the box: FirstMatchStrategy (default): Evaluates all providers in order and returns the first successful result. Providers that indicate FLAG_NOT_FOUND error will be skipped and the next provider will be evaluated. Any other error will cause the operation to fail and the set of errors to be thrown.

  • FirstSuccessfulStrategy: Evaluates all providers in order and returns the first successful result. Any error will cause that provider to be skipped. If no successful result is returned, the set of errors will be thrown.
  • ComparisonStrategy: Evaluates all providers in parallel. If every provider returns a successful result with the same value, then that result is returned. Otherwise, the result returned by the configured "fallback provider" will be used. When values do not agree, an optional callback will be executed to notify you of the mismatch. This can be useful when migrating between providers that are expected to contain identical configuration. You can easily spot mismatches in configuration without affecting flag behaviour.

This strategy accepts several arguments during initialization:

import { WebMultiProvider, ComparisonStrategy } from '@openfeature/multi-provider-web'

const providerA = new ProviderA()
const multiProvider = new WebMultiProvider(
  [
    {
      provider: providerA
    },
    {
      provider: new ProviderB()
    }
  ],
  new ComparisonStrategy(providerA, (details) => {
      console.log("Mismatch detected", details)
  })
)

The first argument is the "fallback provider" whose value to use in the event that providers do not agree. It should be the same object reference as one of the providers in the list. The second argument is a callback function that will be executed when a mismatch is detected. The callback will be passed an object containing the details of each provider's resolution, including the flag key, the value returned, and any errors that were thrown.

Custom Strategies

It is also possible to implement your own strategy if the above options do not fit your use case. To do so, create a class which implements the "BaseEvaluationStrategy":

export abstract class BaseEvaluationStrategy {
    public runMode: 'parallel' | 'sequential' = 'sequential';

    abstract shouldEvaluateThisProvider(strategyContext: StrategyPerProviderContext, evalContext: EvaluationContext): boolean;

    abstract shouldEvaluateNextProvider<T extends FlagValue>(
        strategyContext: StrategyPerProviderContext,
        context: EvaluationContext,
        result: ProviderResolutionResult<T>,
    ): boolean;

    abstract determineFinalResult<T extends FlagValue>(
        strategyContext: StrategyEvaluationContext,
        context: EvaluationContext,
        resolutions: ProviderResolutionResult<T>[],
    ): FinalResult<T>;
}

The runMode property determines whether the list of providers will be evaluated sequentially or in parallel.

The shouldEvaluateThisProvider method is called just before a provider is evaluated by the Multi-Provider. If the function returns false, then the provider will be skipped instead of being evaluated. The function is called with details about the evaluation including the flag key and type. Check the type definitions for the full list.

The shouldEvaluateNextProvider function is called after a provider is evaluated. If it returns true, the next provider in the sequence will be called, otherwise no more providers will be evaluated. It is called with the same data as shouldEvaluateThisProvider as well as the details about the evaluation result. This function is not called when the runMode is parallel.

The determineFinalResult function is called after all providers have been called, or the shouldEvaluateNextProvider function returned false. It is called with a list of results from all the individual providers' evaluations. It returns the final decision for evaluation result, or throws an error if needed.

Building

Run nx package providers-multi-provider to build the library.

Running unit tests

Run nx test providers-multi-provider to execute the unit tests via Jest.