[FEATURE] In-memory provider for js (node) and web SDKs

[toddbaert]

Requirements

As outlined in the specification, the js-sdk should include an in-memory provider implementation. This implementation should take a simple object that defines flags as well as simple rules in the form of lambdas (see equivalent Java implementation, and existing JS implementation in contrib) and use those to evaluate flags. This is very useful to conusmers of the SDK for testing purposes. Please carefully implement all the behaviors defined in the spec for the in-memory provider.

This is a great issue to take on if you're looking to get started in OpenFeature!

@moredip This would be pretty similar to what you implemented in the JS contrib. I think the main thing missing would be rules-based evaluation (some flag "values" would instead define lambdas to run which are passed the context). If you'd like to work on this issue, just assign it to yourself. Otherwise, I will add the good first issue, etc tags to it which I suspect will result in it quickly being picked up.

Tasks

Preview Give feedback

1. web-sdk implementation (packages/client)
2. js-sdk (node) implementation (packages/server)
3. remove existing partial implementation from js-sdk-contrib

[luizgribeiro]

I was looking at both js-contrib inMemoryProvider and the Java Provider mentioned and the structure looks pretty different. The JS one uses object literals to assign values to flags while Java's goes deeper with variants and context evaluator. This part caught my attention from the js:

  async resolveObjectEvaluation<U extends JsonValue>(flagKey: string): Promise<ResolutionDetails<U>> {
    throw new GeneralError('support for object flags has not been implemented');
  }

It is not clear to me if the context aware implementation of js-sdk should be backwards compatible or not.
In terms of docs, content and also getting started with openFeature it would be easier if it was.

What do you think that would be the best approach in this case @toddbaert ?

[toddbaert]

I don't think we have too many docs specifically talking about the current in-memory provider (and if we do have blogs/docs we can update them). I think the most important thing is to have a provider that conforms to the appendix in the spec, and is robust-enough for use in testing, which is the main purpose of the in-memory provider (replace your "real" provider with in-memory in unit testing).

I would not worry about the backwards compatibility. The current one will still be available on NPM regardless. (though we will likely deprecate it).

[luizgribeiro]

Ok.

I'd like to work on the js-sdk-contrib issue. My idea is to:

1. Make it spec compliant (flags definition structure used by provider mostly)
2. Add context aware flag resolution support

It can be done in the js-sdk-contrib repo and the package can be moved to this one afterwards.

If that's ok, assign it to me please