java reactive client

[ashirman]

hello, I have detected that thanks to Spring 5 and Project Reactor more and more projects use so-called reactive approach. To be able to use an existing Launch Darkly client in reactive projects I have to write a kind of boilerplate code to be able to translate existing return types to appropriate reactive types. For example:
public boolean boolVariation(String featureKey, LDUser user, boolean defaultValue)
ideally should look like
public Mono<Boolean> boolVariation(String featureKey, LDUser user, boolean defaultValue)
the wrapper code which I have to use in my-own LD client warapper to get ride of the issue looks like following:
Mono<Boolean> booleanMono = Mono.fromCallable(() -> LDClient.boolVariation(featureKey, user, false)).subscribeOn( Schedulers.elastic());

Do you consider an option to extend existing LD java-client library (or build java-client-reactive) so provide reactive client out of the box? I feel it could be much appreciated by many of your clients who adopt reactive stack.

FYI here is more information about webflux and Project Reactor
https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html
https://github.com/reactor/reactor-core

[eli-darkly]

There are two things we could potentially do. One would be to provide exactly what you've made for yourself: a simple wrapper that just wraps each client method in a Mono, even though the inner workings of the client would still be synchronous. We could probably do this, although I'm not sure anyone here has experience with Reactor so it might be hard for us to be sure that the wrapper is correct.

The other would be to make a new version of the client that actually uses this asynchronous architecture. We are probably not going to do that unless there's significant demand for it.

[ssrm]

reactive feature coming in near future?

[eli-darkly]

It's not on our roadmap at present. As mentioned above, there are two ways this could be done: a wrapper, or an SDK that really uses Reactor internally. The latter would of course be a much larger project; it would be a new SDK that would share some code with the current one, but every part that does any I/O would need to be different. So a wrapper is certainly easier, but it's not clear to me 1. if that would actually be doing anything useful— the SDK's internal operations would still be doing blocking I/O, so it would not really be behaving like a Reactor component is supposed to, as I understand it— and 2. why it is necessary at all; that is, I presume Reactor does not actually prohibit you from calling any method whose return value isn't wrapped in Mono<>, otherwise it would be impossible to use most standard Java classes. So we would need to know a bit more about the requirements. We have just finished a major rewrite of the regular Java SDK so other architectures haven't been on our radar for a while.

[ssrm]

At-least in my case , I am looking to listen changes for specific key rather than listening on all flags and keeping a condition to process further. registerFlagChangeListener(key, lduser, default) and in return I am looking to get current LDValue.

This is much useful if we need to do any asynchronous process.

[eli-darkly]

@ssrm I'm unclear on how that relates to the kind of changes that the original reporter of this issue was talking about. They seem to be about quite different things— boolVariation is an SDK method that is called by application code, whereas change listeners are application code that is called by the SDK.

The flag change listener feature that was added in today's 5.0.0 release (the API you mentioned was from one of the recent beta versions, where it was slightly different) already provides a way to listen for either changes to flag configuration in general, or changes in what the result value would be for a specific combination of one flag and one user (for the latter, use client.getFlagTracker().addFlagValueChangeListener). But I'm not sure what that has to do with Reactor.

[ssrm]

Sorry..I might have hijacked. Yeah I am looking for this client.getFlagTracker().addFlagValueChangeListener). Thanks

[njain3-rms]

Any updates on this. We need a reactive client for our Vertx application.

[eli-darkly]

@njain3-rms Sorry, there aren't any updates. If and when there are, we'll comment on this issue again.

[amardeepkhera]

Up voting this requirement