Open artursouza opened 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.
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.
@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.
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):
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.