Learning the tenets of reactive programming

To launch things, we are going to take advantage of one of Spring Boot's hottest new features--Spring Framework 5's reactive support. The entire Spring portfolio is embracing the paradigm of reactive applications, and we'll focus on what this means and how we can cash in without breaking the bank.

Before we can do that, the question arises--what is a reactive application?

In simplest terms, reactive applications engage in the concept of non-blocking, asynchronous operations. Asynchronous means that the answer comes later, whether by polling or by an event pushed backed to us. Non-blocking means not waiting for a response, implying we may have to poll for the results. Either way, while the result is being formed, we don't hold up the thread, allowing it to service other calls.

The side effect of these two characteristics is that applications are able to accomplish more with existing resources.

There are several flavors of reactive applications going back to the 1970s, but the current one gaining resonance is Reactive Streams due its introduction of backpressure.

Backpressure is another way of saying volume control. The consumer controls how much data is sent by using a pull-based mechanism instead of a traditional push-based solution. For example, imagine requesting a collection of images from the system. You could receive one or a hundred thousand. To prevent the risk of running out of memory in the latter case, people often code page-based solutions. This ripples across the code base, causing a change in the API. And it introduces another layer of handling.

To expand on this example, the following solution would depict that risky collection:

    public interface MyRepository { 
      List<Image> findAll(); 
    } 

This preceding repository could indeed return one Image or a hundred thousand. There's no way to tell. The most common solution, as mentioned, would be to switch to something like this instead:

    public interface MyRepository { 
      Page<Image> findAll(Pageable p); 
    } 

The first solution is simple. We know how to iterate over it. The second solution is also iterable (Spring Data Commons's Page type implements Java's Iterable interface), but requires passing in a parameter to our API, specifying how big a page is and which page we want. While not hard, it introduces a fundamental change in our API.

Reactive Streams is much simpler--return a container that lets the client choose how many items to take. Whether there is one or thousands, the client can use the exact same mechanism and take however many it's ready for. To do this, we would use the following method signature:

    public interface MyRepository { 
      Flux<Image> findAll(); 
    } 

A Flux, which we'll explore in greater detail in the next section, is very similar to a Java 8 Stream. We can take as many as we want and it lazily waits until we subscribe to it to yield anything. There is no need to put together a PageRequest, making it seamless to chain together controllers, services, and even remote calls.