Spring Boot 2. Async API. CompletableFuture vs. Reactive

Question

My application is heavily relying on asynchronous web-services. It is built with spring boot 1.5.x, which allows me to utilize standard Java 8 CompletableFuture<T> in order to produce deferred async responses. For more info see https://nickebbitt.github.io/blog/2017/03/22/async-web-service-using-completable-future

Spring boot 2.0.x now comes with the starter pack that can utilize reactive paradigm. Spring WebFlux is the framework, which is implementing reactive HTTP.

Since I have my API implemented as described in the first paragraph, will I gain much by redoing my services to use non-blocking reactive approach? In a nutshell, I'll have non-blocking API as well, right?

Is there an example how to convert async API that is based on CompletableFuture<T> to Mono<T>\Flux<T>?

I was thinking to get rid of servlet-based server altogether (Jetty in my case) and go with Netty + Reactor.

Needless to say that I am new to the whole reactive paradigm.

I would like to hear your opinions.

Answer 1

I have two things to say:

Q: Is there an example how to convert async API that is based on CompletableFuture to Mono\Flux?

A: 1) You have to configure endpoint in a bit different way https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html

2) CompletableFuture to Mono\Flux example: Mono.fromFuture(...)

Answer 2

As for the question: "will I gain much by redoing my services to use non-blocking reactive approach". The general answer is provided in the documentation: https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-performance .. and it is no.

Performance has many characteristics and meanings. Reactive and non-blocking generally do not make applications run faster. They can, in some cases, (for example, if using the WebClient to run remote calls in parallel). On the whole, it requires more work to do things the non-blocking way and that can slightly increase the required processing time.

The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory. That makes applications more resilient under load, because they scale in a more predictable way. In order to observe those benefits, however, you need to have some latency (including a mix of slow and unpredictable network I/O). That is where the reactive stack begins to show its strengths, and the differences can be dramatic.

This is general answer, but the specifics will depend and you must measure and see. I would start by recreating a simple part of the application and checking the performance of both in an isolated environment.