Async/Non-Blocking Feature Evaluation

[aelfric]

I notice in the javascript API, getBooleanValue returns a Promise<boolean> instead of boolean. Would it be possible to have an API like this in the Java case that would support non-blocking use-cases. An example would be, for example, in a Spring WebFlux service where evaluation is based on the some attributes of the current request and needs to delegate evaluation to another external service.

[guidobrei]

Personally, I would also prefer a Non-Blocking over a blocking API, like in our JS or the .Net APIs, but this would require all Provider implementations to adopt.

However, afaik many of the providers support in-process evaluation and fetch flag configurations in the background. This makes flag evaluation a CPU bound task which could be made "async" by wrapping it on the top level.

If you really have a provider that depends on remote evaluation there is currently no way to make it async.

[guidobrei]

Just found out that Python SDK also starts supporting async evaluation with this PR.

It's also encouraged by the spec:

The client SHOULD provide asynchronous or non-blocking mechanisms for flag evaluation.

[aelfric]

Since it's a SHOULD in the spec rather than a MUST, would ask the providers really need to adopt it immediately? I took a quick glance at that python PR and there seem to be follow-up items there to promote adoption. It wouldn't have to be a bing-bang change.

In my use-case, feature evaluation requires a REST call to another service, the value will be different depending on details of the current user, and it's not practical to load feature values for all possible users at application startup.

[beeme1mr]

We could definitely take a similar approach to what we did in Python. I think, realistically, it's the only way we could add async support without causing serious impact to all existing providers.

FYI @toddbaert @aepfli @justinabrahms @liran2000