First class client-side support in OpenFeature spec #167

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.

• 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 007-OFEP-flag-change-events ofep#25
  • also valuable on the server
• "shutdown" functionality
  • providers may setup listeners, timers, that need to be closed
  • see feat: add proposal for dispose functionality ofep#30
  • also valuable on the server
• 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 Research for "bulk evaluation" functionality ofep#13
• 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: Add "static-context" paradigm OFEP ofep#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: Add "static-context" paradigm OFEP ofep#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: Add "static-context" paradigm OFEP ofep#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.