Non Blocking APIs with Project Reactor

Project Reactor is a reactive streams API for building performant, non-blocking applications for Java based languages. It is based on the reactive-streams library that also underpins RxJava 2.x.

Benefits of Project Reactor

1. Project Reactor provides Reactor-Netty, a non-blocking and backpressure-ready TCP / HTTP / UDP library. Whilst there exists RxNetty for RxJava, this appears to be largely abandoned. In previous incarnations of the Azure SDKs, a custom layer was written to act as a go-between from Netty to RxJava, and this was error-prone, buggy, and the cause of major support demands. Relying instead on Reactor-Netty absolves us of this overhead, and it has been battle-tested in highly demanded Spring workloads.

2. Project Reactor has baselined on JDK 8, which is also where Microsoft is baselining for the Java Azure SDK. This means it is more idiomatic to a Java developer, benefitting from support for Streams, functional interfaces / lambdas, new date / time, etc. RxJava does not support these new language features as it has baselined on JDK 6.

3. Project Reactor has the BlockHound Java agent that can detect blocking calls from non-blocking threads, aiding development of fully non-blocking client libraries.

4. Project Reactor enables our synchronous client libraries to be built with blocking asynchronous calls. Project Reactor developers have assured us that this is a pattern that they support, that there are no threading concerns here, and that this is a pattern that they themselves have had implemented in their Spring framework and other libraries. We have also run considerable performance benchmarks on this approach and find that sync over async works exceedingly well. This results in a far lesser amount of code needing to be written and maintained to support synchronous and asynchronous client libraries, as well as removing the need for maintaining separate transport layers for asynchronous and synchronous HTTP clients.

5. Project Reactor has reactive bridges for Apache Kafka and RabbitMQ that will be beneficial for future libraries.

6. Project Reactor has additional libraries for testing, additional Flux operators, and adapters for converting to / from other reactive libraries.

7. Project Reactor is backed by Pivotal, with full time engineering effort by a number of employees. Pivotal employees have been available to present, share knowledge, review prototype code, and answer questions, and are a continuing source of feedback. RxJava does not have any corporate backer and is maintained by open source contributors. Support is more difficult to attain and is necessarily directed via community support forums such as Stack Overflow.

8. Project Reactor has invested heavily in quality learning materials, as well as a comprehensive reference guide and API reference documentation.

9. Project Reactor gives us an extremely clear message for users, because all operations can be classified as either a Mono (containing zero or one result) or a Flux (containing zero or more results). This means users can have clarity over what to expect, and we can also scale from operations that return one result to a few results to long-running streaming patterns all with the same set of APIs.

Other Points

1. David Karnok, lead contributor to the RxJava project (as well as contributor to the shared reactive-streams library that is used by both RxJava and Project Reactor) has stated publicly to "Use Reactor if you are allowed to use Java 8+, use RxJava 2 if you are stuck on Java 6+ or need your functions to throw checked exceptions".

2. Public consensus (as retweeted by David Karnok, RxJava project lead) is trending towards Project Reactor: "looking forward, Reactor is definitely more promising. Its performance seems better, development is more active and backed by a bigger player (Pivotal). These libraries are quite similar (at least from an API perspective) but if you get a choice, Reactor will probably serve you better."