Create a Reactive Stream as an extension
otaviojava opened this issue · comments
Goal
The goal of this proposal is to write an extension to each API that allows integration with Reactive Streams API.
Briefly, Reactive Stream is an initiative to provide a standard for asynchronous stream processing with non-blocking backpressure.
This extension will work integrated with the Eclipse MicroProfile Reactive Streams Operators.
About Reactive Streams
Reactive Streams is an integration SPI - it allows two different libraries that provide asynchronous streaming to be able to stream data to and from each other.
Reactive Streams is not however designed to be used directly by application developers. The semantics defined by Reactive Streams are very strict, and are nontrivial, particularly in the areas of thread safety, to implement correctly. Typically, application developers are expected to use third-party libraries that provide the tools necessary to manipulate and control streams. Examples include Akka Streams, RxJava, and Reactor.
Repository
The repositories programming model is the most high-level abstraction and we'll have a repository to handle with ReactiveRepository:
public interface GodRepository extends ReactiveRepository<God, String> {
}String id =...;
Publisher<God> publisher = repository.findById("id");
CompletionSubscriber<God, Optional<God>> subscriber = ReactiveStreams.<God>builder().findFirst().build();
publisher.subscribe(subscriber);
CompletionStage<Optional<God>> completion = subscriber.getCompletion();Templates
Just as the traditional repositories are based on traditional template implementations, the reactive ones are built on top of a reactive template.
- ReactiveKeyValueTemplate
- ReactiveDocumentTemplate
- ReactiveColumnTemplate
ReactiveKeyValueTemplate template
Publisher<God> publisher = template.get("id", God.class);
CompletionSubscriber<God, Optional<God>> subscriber = ReactiveStreams.<God>builder().findFirst().build();
publisher.subscribe(subscriber);
CompletionStage<Optional<God>> completion = subscriber.getCompletion();References:
This is a similar situation as #203. While it seems fine for JNoSQL to use a MicroProfile library in an implementation, it is not acceptable for the Spec/API (Jakarta NoSQL)
And do not forget the Java 9 Flow API, it should be supported, like Spring Data, as an addon of the ReactiveStreams spec, which can be converted between different ReactiveStreams impls.
@otaviojava Did you look at https://spring.io/projects/spring-data-r2dbc? As for which API you are going to support, I think supporting Java 9 Flow is better than org.reactivestreams APIs. However, you can use the Reactive Streams RxJava, Reactor, Akka for implementations. Adopting MicroProfile Reactive Streams Operators is a great idea as well.
@Emily-Jiang
Currently, Jakarta EE 8 has support for Java 8; therefore, we cannot use Java 9.
Hopefully, Reactive Streams Operators can have an implementation that has support to Flow in Java 9 or higher.
@otaviojava I do not think it is conflict when adopting Java 9 Flow APIs. We can handle it like Spring Data, support ReactiveStreams spec/Microprofile ReactiveStreams Operators which are Java 8 based, and add addons to support Java 9 Flow, Reactor, RxJava 1/2/3, SmallRye Munity, etc.
@hantsy That sounds like a good plan :)
@otaviojava/all, please don't forget, that the final NoSQL release won't even be relevant to the Jakarta EE platform before Jakarta EE 10, so it is more than reasonable to consider adopting to Jakarta EE 9 now. Which is based on Java SE 9 or even 11, therefore all those reactive technologies could be fine, particularly for the implementation, as long as they are usable by Eclipse projects.
@keilw Eclipse MicroProfile uses interfaces, that means we can use Flow as implementation.
Right now there three implementations on Eclipse MicroProfile:
- Akka Streams
- Zero Dependency - intended as a possible reference implementation for when this is proposed to the JDK, but not the reference implementation for MicroProfile as MicroProfile does not have reference implementations.
- SmallRye - based on RxJava 2 and Eclipse Vert.x.
What do you think about this Eclipse MicroProfile project?
Does it have a bright future?
Does it worth creating this kind of extension?
@otaviojava I think it is a good idea to adopt MicroProfile Reactive Streams Operators even though in the future the APIs might change. I will be interested in any feedback you might have.
By the way, I would not investigate any time to Zero Dependency as it is not maintained or used by any runtime. Focusing on SmallRye is the right thing to do.
@Emily-Jiang @otaviojava Note, that Jakarta EE has stronger compatibility requirements, therefore a frequently changing API is no good. Let's wait till MicroProfile becomes more mature and especially for the API it can't be used until there is a resolution by the various committees following such committee or WG on the MP side, a current version of MP Reactive Streams can't be used. Isn't SmallRye just one implementation? Jakarta NoSQL and JNoSQL should work with all Jakarta EE compatible runtimes and implementations. As mentioned there is no RI for MP either, but compared to the other two Lightbend implementations it seems that SmallRye is a little more up do date and better-maintained. Also the number of dependencies looks fewer, so it could be a good option, but we'd have to evaluate more carefully before making a decision.
@keilw
I agree with you Werner, that why we'll create it as an extension and not directly in the RI.
The goal to achieve here is an extension to get feedback from the community.
I think I would rather stick to something like https://github.com/reactive-streams/reactive-streams-jvm. "For this reason, the same interfaces provided by https://www.reactive-streams.org in the org.reactivestreams package are used instead." so MP Reactive does nothing more than use this library. If we want to use the nifty diagrams. then we may also consider using the MP project but similar to MP OpenAPI it is just a think layer or glue to another existing spec, so the spec or API it uses is of greater value here.
But what does that mean for the PR, would it work now or only after adopting Java 11?
@keilw it will work on both now and later with less impact to the users.
Now Jakarta EE 10 is aligned to Java 11, I think it is time to add ReactiveStreams. I think using Java 9 Flow API is OK.
(Java 11 HttpClient is a good example of using Flow API, eg. HttpResponse.BodySubscriber).
There are some utilities in reactivestreams.org to convert between Flow and ReactiveStreams.
And it seems SmallRye Mutiny is switching to use Flow API instead, smallrye/smallrye-mutiny#986
We'll close this idea for awhile.
We'll focus on the Jakarta Data and NoSQL implementation.