Learning Spring Boot 2nd Edition 80% complete w/ Reactive Web

This weekend I sent in the first draft for Chapter 2 – Reactive Web with Spring Boot (of Learning Spring Boot). Even though this is Chapter 2, it’s 80% of the book. That’s because I’m writing Chapters 2, 3, and 4 last, due to the amount they depend on Reactive Spring.

This may sound rather awkward given Spring Boot has yet to release any tags for 2.0. Pay it note, there is a lot of action in Spring Framework 5.0.0 such that it’s already had several milestones. A big piece of this book is getting a hold of those reactive bits and leveraging them to build scaleable apps. The other part is how Spring Boot will autoconfigure such stuff.

Thanks to Spring guru Brian Clozel, there is an experimental project that autoconfigures Spring Boot for Reactive Spring, and will eventually get folded into the Spring Framework. Bottom line: Reactive Spring is available for coding today, albeit not with every feature needed. But since the target release date is May, there will be time for spit and polish against the book’s code base.

And now, an excerpt from Chapter 2, for your reading pleasure:

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 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 embrace the concept of non-blocking, asynchronous operations. Asynchronous means that the answer is coming 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 aren’t holding 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 sthe risk of running out of memory in the latter, 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.

For example, instead having a solution return a risky collection like this:

public interface MyRepository {
List findAll();
}

We would instead switch to something like this:

public interface MyRepository {
Page 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.

public interface MyRepository {
Flux 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 just as many as we want and lazily waits until we subscribe to it to yield anything. There is no need to put together a PageRequest, making it seemless to chain together controllers, services, and even remote calls.

Hopefully this has whet your appetite to code against Reactive Spring.