Hi Santiago,
Great questions.
Reactive Streams has a number of sweet spots where it adds a lot of value, and then a number of places where it's useful, but doesn't add as much value. The biggest sweet spot is in messaging, and the first place we are working on in MicroProfile is in handling messaging on top of message brokers, eg Kafka. I don't see any immediate adoption of it in the context of using REST/JAX-RS in MicroProfile, rather, from my point of view, MicroProfile is sorely missing a standard for asynchronous communication between services to complement the existing REST/JAX-RS APIs, so this new Reactive Streams based messaging spec will fill that gap.
That said, once you have a Reactive Streams based messaging API, this opens a number of possibilities with regards to both WebSockets and SSE, where it's often useful to connect these endpoints into some form of messaging API, and Reactive Streams works well to do that.
For streaming output use cases are probably where Reactive Streams is least useful. That's not to say it's not useful, it's just not as useful as in messaging. The advantage of using something like Reactive Streams for the streaming use cases is that it makes it easy to plumb multiple asynchronous streaming sources/sinks together from different technologies - for example, streaming a database blob out to a an HTTP connection. We're still a fair way from getting to that of course - for example there's no real usable solution for talking to a database using asynchronous IO at the moment, of course Oracles ADBA effort will hopefully change that and I have been in communication with the developers of that, Reactive Streams is being adopted there.
A few months ago I wrote a high level overview of where I see Reactive Streams being potentially useful in Jakarta EE. Actually missing from that is mention of JAX-RS, though it's a similar story to the what I wrote about for the Servlet API:
Cheers,
James
