Hands-On Reactive Programming in Spring 5

上QQ阅读APP看书，第一时间看更新

Project Reactor version 2.x

Not long after the first official release of Reactor 1.x, Stephane Maldini was invited to the Reactive Streams Special Interest Group as an expert in high-performance message processing systems and a Project Reactor co-lead. This group, as we may guess, worked on the Reactive Streams specification. After gaining a better understanding of the nature of Reactive Streams and introducing new knowledge to the Rector team, Stephane Maldini and Jon Brisbin announced Reactor 2.x in early 2015. Citing Stephane Maldini: "Reactor 2 was the first shot at Reactive Streams".

The most significant change in Reactor design was in extracting the EventBus and Stream features into separate modules. Also, a deep redesign enabled the new Reactor Streams library to become fully compliant with the Reactive Streams specification. The Reactor team dramatically improved the API of Reactor. For example, the new Reactor API had better integration with the Java Collections API.

With the second version, Reactor's Streams API became much more similar to the RxJava API. Along with simple additions to create and consume streams, there were a bunch of useful additions for backpressure management, thread dispatching, and resilience support, as follows:

stream
   .retry()                                                          // (1)
   .onOverflowBuffer()                                               // (2)
   .onOverflowDrop()                                                 //
   .dispatchOn(new RingBufferDispatcher("test"))                     // (3)

The previous example shows three simple techniques:

With the one-line operator retry, we introduce resilience into the flow and, in the event of errors, upstream operations should run again.
With the onOverflowBuffer and onOverflowDrop methods, we add backpressure control for when a publisher supports only the push model (and cannot be controlled by consumer demand).
At the same time, by applying the dispatchOn operator, we dedicated a new Dispatcher to work on that reactive stream. This preserves the ability to process messages asynchronously.

The Reactor EventBus was also improved. First of all, the Reactor object, which is responsible for sending messages, was renamed EventBus. The module was also redesigned to support the Reactive Streams specification.

Around that time, Stephane Maldini met David Karnok, who was actively working on his dissertation High resolution and transparent production informatics. The dissertation reports in-depth research in the field of Reactive Streams, Reactive Programming, and RxJava. In close collaboration, Maldini and Karnok condensed their ideas and experience of RxJava and Project Reactor into a library called reactive-stream-commons. A bit later, that library became the foundation of Reactor 2.5, and finally, Reactor 3.x.

The source of the reactive-streams-commons library is available for exploration at the following GitHub project page: https://github.com/reactor/reactive-streams-commons.

After a year of hard work, Reactor 3.0 was released. At the same time, a pretty identical RxJava 2.0 surfaced. The latter has more similarities with Reactor 3.x than with its predecessor, RxJava 1.x. The most notable difference between those libraries is the fact that RxJava targets Java 6 (including Android support) while Reactor 3 chose Java 8 as a baseline. Meanwhile, Reactor 3.x shaped a reactive metamorphosis of Spring Framework 5. This is why Project Reactor is used extensively in the remaining chapters of this book. Now, we are going to learn about the API of Project Reactor 3.x and how to use it effectively.