Repository navigation
Async/Non-Blocking Feature Evaluation #1397
Description
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.
Activity
guidobrei commentedon May 7, 2025
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 commentedon May 7, 2025
Just found out that Python SDK also starts supporting async evaluation with this PR.
It's also encouraged by the spec:
aelfric commentedon May 7, 2025
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 commentedon May 7, 2025
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