Superposition Provider - what is it?

[knutties]

Superposition Provider (aka ConfigurationResolver)

Superposition Provider is a library that allows applications that use Superposition as their configuration backend to resolve configurations in their application code.

note: ConfigurationResolver or just Resolver seems like a better name than provider for the library. The Provider name is a overhang from the OpenFeature provider terminology.

Capabilities

Primary capabilities

The provider should support both of the following configuration capabilities.

• Resolve configuration given single key and evaluation context + targetting key (standard openfeature interface) - (this is captured using FeatureProvider Interface of Open Feature)
• Resolve full configuration given the evaluation context + targetting key - (we can introduce a new interface that has one method to get all the configuration. This interface can be called AllFeatureProvider.)

If the provider supports experimentation it should in addition support the following experimentation capabilities (these capabilities can be encapsulated in a new interface called FeatureExperimentationMeta Interface).

• return experiments matching the given EvaluationContext
• returns variants into which the targettingKey slotted into for given EvaluationContext and targettingKey.

Flavours

The Superposition providers are classified into two flavours depending on where the resolution happens - the resolution can happen in the process space of the application integrating with Superposition or it can happen remotely with the application just getting the resolved configuration.

In-process resolution (aka local resolution)

This flavour uses our evaluation function exposed via FFI natively in each supported programming language and resolves the configuration in-process using the given context and targetting_key. This provider should provide the following capabilities:

• multiple data source support
  • Sources include
    • http (needed by main app use-case inside Juspay)
    • redis (needed by airborne)
    • file (needed by hyperswitch and UCS)
• since the superposition raw data can be cached, following refresh mechanisms are to be supported by the in-process (aka local provider):
  • refresh the raw data manually (refresh manually)
  • refresh the raw data periodically (POLL with frequency)
  • on-demand fetch raw data and run resolution locally
  • on-change - watch/listen for raw data changes (applicable to only file for now)
  • use last known good version if refresh fails
• The data-source behaviour can be modelled using an interface called SuperpositionRawDataSource which should support the access to both experimentation and configuration data (fetched from the source) that the Superposition core evaluation logic needs.
  • config
    • default_config
    • contexts
    • overrides
    • dimensions
  • experimentation data
    • experiment data
    • experiment groups data
• the SuperpositionRawDataSource interface should support context filtering for both the config/experimentation accesses - so subset contexts can be retrieved by applications in case they don't need the full context.

Remote resolution

In this flavour the context and targetting_key are sent over the network and resolved config is obtained from the remote source. It could be available in the following flavours.

• http based remote resolution (SuperpositionAPIProvider) - (Namma Yatri)
• redis module remote resolution (SuperpositionRedisProvider)
• db based remote resolution (SuperpositionDBProvider)

Other features

• support caching of resolution output
  • For providers which support in-process resolution - all resolution caching is local with ttl and max cache entries (or cache size) support
  • For providers which support remote resolution - caching is to be handled by the providers themselves (using either local or remote caches)
• Registry support for managing multi-providers
• Evaluate need to support Primary and Fallback data source (fallback is used only if primary fails on startup)

Language support

Resolution support is to be provided in all popular programming languages.

• Java
• Python
• Javascript
• Rust
• Go
• Swift
• Kotlin (as it supports okhttp which is available in Android)

Implementation expectations

1. Define the AllFeatureProvider interface
2. Define the FeatureExperimentMeta interface
3. Define the SuperpositionRawDataSource interface
4. Implement a http source for the SuperpositionRawDataSource interface (the existing provider crate already has this logic)
5. Implement a LocalResolutionProvider that implements the FeatureProvider, AllFeatureProvider and FeatureExperimentMeta interface and takes in a SuperpositionRawDataSource implementation for fetching the raw data.
6. The LocalResolutionProvider should implement all the refresh mechanism capabilities described above.
7. Implement a file source for the SuperpositionRawDataSource interface - the file source can be implemented using on the superposition_toml crate at https://github.com/juspay/superposition/tree/cac-toml/crates/superposition_toml. In this case there will be no experiment data and the data source will return empty values for the same.
8. Include two examples one with the LocalResolutionProvider using the http source (item 4) and one using the file source (item 7).
9. Implement a RemoteResolutionProvider called SuperpositionAPIProvider which implements the AllFeatureProvider and the FeatureExperimentMeta interfaces.

[mahatoankitkumar]

Didn't get what is db based remote resolution?

[knutties]

We will implement a PostgreSQL module where:

select key from db where dimension1 = 'foo' and dimension2 = 'bar'

will actually behave like Superposition resolve - so that it will appear as if native DB has hierarchical nature.