search

dapr / java-sdk

Dapr SDK for Java
Apache License 2.0
258 stars 204 forks source link

Remove Reactor (Mono) and use CompletableFuture #964

Open artursouza opened 9 months ago

artursouza commented 9 months ago

Describe the proposal

Before Project Reactor, I used CompletableFuture for async programming in Java. When writing the first complete version for this SDK, Project Reactor was the recommended async programming model - it was (probably still is) used by the Azure's Java SDK.

Based on my experience in the last few years and a few in person conversations about Project Reactor, I would like to propose this SDK to move into using CompletableFuture. For me, my biggest problem with Project Reactor is how it completely changes the programming model for Java, having a sub-syntax of its own, while also forcing apps that don't want to use Project Reactor to have this dependency forced on them if they want to use Dapr with Java. It means a new interface, not depending on Project Reactor at all, keeping the existing implementation for 2 releases (deprecation path for the Dapr Project).

For projects that depend on the current interface and don't want to change any code (like wrapping CompletableFuture into a Mono object), we can still offer the existing interface via a new artifact (dapr-sdk-reactor, or some similar name).

In summary, these are the benefits for this change (in order of importance):

  1. Apps that don't want to use Project Reactor, will not be forced to use it or even have it as a dependency.
  2. Apps that want to operate as-is, will still have a path forward, requiring just to add a new dependency to their pom.xml file and all the CompletableFuture interfaces will be available as wrapped inside a Mono.
  3. Lower barrier of entry to contribute, since people that are not familiar with Reactor can contribute without having to re-learn a new "language".
  4. Simplify the SDK's code readability and debugging.

What does the community think about this change? Please, react (pun not intended) to vote: 👍 We need this ASAP. 👎 Let's keep it as-is today. 😕 Need more time to think.

PS: I know this can be a controversial proposal as I have heard passionate opinions both ways on this matter.

rob-dotmatics commented 9 months ago

I can totally understand the justification for removing Reactor as a dependency from the main DAPR SDK artifact, and support this change. Indeed if we weren't using Reactor / WebFlux already, I might take issue with having to pull in those dependencies to use the DAPR client.

It is very helpful that Mono wrappers are being proposed alongside this change, as we have several WebFlux / Reactor services that benefit from the current Mono interface to DAPR.

salaboy commented 9 months ago

One thing that I would like to mention, is compatibility with Spring Boot 3.x.. whatever we do, we should try to follow their lead to make sure that we don't go to a place where Spring Boot users find issues because we choose to use something that will not work with that stack.

artur-ciocanu commented 1 month ago

@artursouza I really like idea. One thing I would like to mention is that we should probably use CompletionStage instead of CompletableFuture. Depending on an interface is always easier to test and we could potentially have our own optimized CompletionStage implementation if required, for whatever reason.