We have previously mentioned that there are a lot of patterns and programming techniques that are capable of becoming building blocks for the reactive system. For example, callbacks and CompletableFuture are commonly used to implement the message-driven architecture. We also mentioned reactive programming as a prominent candidate for such a role. Before we explore this in more detail, we need to look around and find other solutions that we have already been using for years.

In Chapter 1, Why Reactive Spring?, we saw that Spring 4.x introduced the ListenableFuture class, which extends the Java Future and makes it possible to leverage the asynchronous execution of operations such as HTTP requests. Unfortunately, only a handful of Spring 4.x components support the newer Java 8 CompletableFuture, which introduces some neat methods for asynchronous...

For some time, there was a standard library for reactive programming on Java platforms—namely RxJava 1.x (see https://github.com/ReactiveX/RxJava for more details). That library paved the way for reactive programming as we know it in the Java world today. At the moment, it is not the only library of this kind; we also have Akka Streams and Project Reactor. The latter is covered in detail in Chapter 4, Project Reactor - the Foundation for Reactive Apps. So, currently, we have a few options from which we may choose. Furthermore, RxJava itself has changed a lot with the release of version 2.x. However, to understand the most basic concepts of reactive programming and the reasoning behind them, we will be focusing on the most fundamental part of the RxJava only, on the API, which has...

Now that we are acquainted with RxJava and have even written a few reactive workflows, let's look at its history to recognize the context in which reactive programming was born and the problems it was designed to solve.

Curiously, the RxJava history and the history of reactive programming as we know it today began inside of Microsoft. In 2005, Erik Meijer and his Cloud Programmability Team were experimenting with programming models appropriate for building large-scale asynchronous and data-intensive internet service architectures. After some years of experimenting, the first version of the Rx library was born in the summer of 2007. An additional two years were devoted to different aspects of the library, including multithreading and cooperative re-scheduling. The first public version of Rx.NET was shipped on November 18, 2009. Later...

In the previous sections, we learned how to use pure RxJava and how to combine it with Spring Web MVC. To demonstrate the benefits of this, we have updated our temperature-monitoring application and improved the design by applying RxJava. However, it is worth noting that Spring Framework and RxJava is not the only valid combination. A lot of application servers also value the power of the reactive approach. As such authors of a successful reactive server called Ratpack decided to adopt RxJava as well.

Along with callbacks and a promise-based API, Ratpack provides RxRatpack, a separate module that allows to convert Ratpack Promise to RxJava Observable easily, and vice versa, as shown in the following code:

Promise<String> promise = get(() -> "hello world");
RxRatpack
   .observe(promise)
   .map(String::toUpperCase)
   .subscribe...

In this chapter, we have revisited a few well-known design patterns by GoF—including Observer, Publish-Subscribe, and Iterator to build the basis of reactive programming. We have written a few implementations to review both the strong and weak sides of the instruments we already have for asynchronous programming. We have also leveraged Spring Framework support for Server-Sent Events, WebSockets, and also played with Event-Bus provided by Spring. Also, we have used Spring Boot and start.spring.io for fast application bootstrapping. Even though our examples were pretty simple, they demonstrated the potential issues that arise from immature approaches that are used for asynchronous data processing.

We also looked at reactive programming's history to highlight architectural problems, which reactive programming was invented to fight against. In this context...