First class client-side support in OpenFeature spec

[toddbaert]

This is a high level issue where I'll try to collect various settled and ongoing discussions pertaining to improvements to OpenFeature for use in client applications.

Required functionality

Below are some features that may need to be specified for effective client usage, many of which are also valuable on the server. I've checked discussions which are mostly settled, and left unchecked topics which I believe are still in contention. I will strike out (like ~this~) features that we don't believe should be implemented.

• [x] events
  • ready events, change events, etc, are useful for client contexts
  • providers may do evaluation "up front" and then signal readiness
  • change events might need to be scoped to prevent huge payloads when configurations change
  • see https://github.com/open-feature/ofep/pull/25
  • also valuable on the server
• [x] "shutdown" functionality
  • providers may setup listeners, timers, that need to be closed
  • see https://github.com/open-feature/ofep/pull/30
  • also valuable on the server
• [x] synchronous API (evaluation functions that do not return promises/tasks/futures or take callbacks)
  • given the existence of readiness events, synchronous evaluation will likely make things easier for developers (avoids loaders, spinners, etc)
• [ ] bulk evaluation
  • bulk evaluation may be useful, especially for evaluating flags "up-front" before providers signal readiness
  • may pose challenges for analytics (reduced visibility)
  • may not be necessary - we might make this a concern of providers
  • see https://github.com/open-feature/ofep/issues/13
• [x] function(s) to reconcile context changes (a means to tell providers to "re-evaluate" their cached flag values)
  • this is analgous to methods in some vendor SDKs: LaunchDarkly, Flagsmisth
  • such functions may be necessary if we implement synchronous evaluation
  • see: https://github.com/open-feature/ofep/pull/41

Open questions

Below are some open questions that will inform, and be informed by the required functionality above.

• ~should the client implementations use the same APIs as the server-side implementations?~
  • ~if not, should the client implementation somehow "wrap" or be implemented on top of the existing APIs?~
  • ~if we want synchronous APIs, this may prove challenging~
  • tentative conclusion: we need distinct APIs for better client support, see: https://github.com/open-feature/ofep/pull/41
• in client usage, do we consider context to be "more static" (associated with a logged in user?) and modified independently of evaluation?
  • should context be removed from evaluation functions in this case?
  • tentative conclusion: yes, we believe we need a "single user" paradigm for better client support, see: see: https://github.com/open-feature/ofep/pull/41
• should we encourage vendors write a single provider for both the the client and server?
• we've been mostly focusing on web, but are there any considerations to take into account specifically for iOS and Android?
  • would we want both sync and async APIs for these platforms?
• is bulk evaluation useful application authors?
  • tentative conclusion: we do not believe we want to expose a bulk evaluation function. We think this will negatively impact telemetry features and add confusion, and only be minimally useful, based on information from vendors who support or considered support for this feature.

[justinabrahms]

These are notes on mobile use-cases: https://github.com/open-feature/ofep/issues/34

[toddbaert]

We had a few takeaways from our Jan20 client-side meeting:

Key Takeaways:

• Investigate “partial context updates”

I think this might be achieved reasonably as described here

• Investigate whether completely removing the “client” abstraction from the spec in single context mode is possible/optimal

• We lose per client hooks (probably not that valuable on the client)
• We lose per client loggers (in some SDKs, probably not that valuable on the client)
• Though we only store minimal state on the client, in the future we could store additional state (such as per-client providers, or other abstractions)
• The evaluation API would now on the globalton, which makes mocking/testing/DI more difficult
• Client SDKs will become even more conceptually divergent from server SDKs without a client
• For these reasons, I don't recommend we remove the client abstraction in static-context mode.

• Investigate need for a new “reason” (or other solution) to indicate if evaluated flags are “stale” or “non-authoritative” before providers have updated their cache

I think this is something we'll want. I've added a STALE reasons to the spec PR in question.

• Create a refined document/summary that we could provide to vendors and get feedback/buy-in on

I will work with @moredip on this.