[Feature Request] Reactive API

[patpatpat123]

Description

Hello Elastic team,

I wanted to reach out asking for a possible enhancement request please. This elasticsearch-java project proposes a blocking api. Adding to that it proposes async api. Those two are already great, many thanks.

However, it is currently lacking a reactive api, just to clarify, async does not mean reactive.

Many applications nowadays are reactive (not just async).

Would it be possible to enrich this project with reactive api which respects the reactive manifesto please?

[swallez]

This has been suggested a few times already and we also had conversations with members of the Reactiverse project on this topic.

So far my conclusions are the following:

• for API methods that return a single result, a reactive version may not be that useful as all reactive frameworks provide easy conversions from CompletableFuture to Mono, Uni, etc.
• reactive implementations however would make sense for API methods that expect a stream of inputs like bulk ingestion, or that span several request like scroll and point-in-time.

So this is something we can add on the roadmap. The implementation will be based on the JDK's java.util.concurrent.Flow though and not the original org.reactivestreams as reactive frameworks are now moving to JDK's interfaces.

[patpatpat123]

"reactive implementations however would make sense for API methods that expect a stream of inputs like bulk ingestion, or that span several request like scroll and point-in-time." -> Precisely our usecase! Fingers crossed with hope on this. Thank you @swallez

[tongdaoqa]

This would be an amazing feature. Fingers crossed for reactive support in elasticsearch java

[NavidMitchell]

I do like the reactor framework in terms of ease of use. I would caution the use of it exclusively for the elastic client. Since this is the data access layer and performance here is critical to many applications. @mostroverkhov found different performance related problems with the implementation of Springs Project Reactor, that will affect large applications at scale. You can read about them here. https://jauntsdn.com/post/rsocket-million-streams-2/

[mostroverkhov]

@NavidMitchell People at RedHat ended up with similar conclusions for several use cases. Library choice depends on preferred framework of target audience - quarkus users likely prefer smallrye-mutiny, while ones of springboot would take reactor.

[tongdaoqa]

There is a much simpler way without adding too much weight to this repo with an external framework.

By leveraging Java built-in Flow, this repo can have reactive features, while keeping things simple I think