In the last chapter, we took a quick tour through the Spring Initializr site at http://start.spring.io. Let's go back there and pick some basic ingredients to start building our social media site by picking the options needed as shown in the following screenshot:

As shown in the preceding screenshot, we've picked the following options:

• Build system: Gradle
• Spring Boot Version: 2.0
• Group: com.greglturnquist.learningspringboot
• Artifact: learning-spring-boot

For dependencies, we are going to use these:

• Reactive Web: This pulls in Reactive Spring, something we'll explore here and through the rest of this book
• Lombok: This is a tiny library that keeps Java interesting by handling getters, setters, toString, equals, hashCode, and more
• Thymeleaf: This is not Boot's only supported template library, but...

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...

We've mentioned Reactive Streams with little detail. There is a spec for Reactive Streams (http://www.reactive-streams.org/), but it's important to understand that it is quite primitive. In fact, it's so primitive that it's not very effective for building applications. That may sound counterintuitive, but it wasn't written so much for end users as it was for framework developers. To build reactive applications, we'll use Project Reactor (http://projectreactor.io/), the core library that Spring Framework 5 uses for its reactive programming model.

To introduce Reactor's core types, we'll begin with the one we just saw in the previous section, Flux, and some code like this:

    Flux.just("alpha", "bravo", "charlie"); 

This simple creation of a Reactor Flux can be detailed as follows:

...

By default, Spring Boot is geared up to use embedded Netty (http://netty.io). Why? Because it's one of the most popular solutions for reactive applications. And when it comes to reactive applications, it's critical that the entire stack be reactive.

However, it's possible to switch to another embedded container. We can experiment with using Apache Tomcat and its asynchronous Servlet 3.1 API. All we have to do is to make some tweaks to the dependency settings in build.gradle, as follows:

    compile('org.springframework.boot:spring-boot-starter-webflux') { 
      exclude group: 'org.springframework.boot', 
      module: 'spring-boot-starter-reactor-netty' 
    } 
    compile('org.springframework.boot:spring-boot-starter-tomcat') 

What's happening in the preceding code? This...

Ever heard of Spring MVC? It's one of the most popular web frameworks used by the Java community. Since Spring Framework 3, it has utilized an annotation-driven programming style, sometimes known as @MVC.

But we aren't going to use that in this book. Instead, we are going to use something new, Spring WebFlux. WebFlux is an alternative module in the Spring Framework focused on reactive handling of web requests. A huge benefit is that it uses the same annotations as @MVC, along with many of the same paradigms while also supporting Reactor types (Mono and Flux) on the inputs and outputs. This is NOT available in Spring MVC. The big thing to understand is that it's just a module name--spring-webflux versus spring-webmvc.

Let's start with a simple HTTP GET. Similar to Spring MVC endpoints, Spring WebFlux supports Flux operations as shown here:

    @GetMapping(API_BASE_PATH + "/images") 
    Flux<Image> images() { 
      return Flux.just( 
        new Image("1", "learning-spring-boot-cover.jpg"), 
        new Image("2", "learning-spring-boot-2nd-edition-cover.jpg"), 
        new Image("3", "bazinga.png") 
      ); 
    } 

This preceding controller can be described as follows:

• Using the same Flux.just() helper, we return a rather contrived list
• The Spring controller returns a Flux<Image> Reactor type, leaving Spring in charge of properly subscribing to this flow when the time is right

Before we can move forward, we need to define this Image data type like this:

    @Data...

The first rule of thumb when building web apps is to keep Spring controllers as light as possible. We can think of them as converters between HTTP traffic and our system.

To do that, we need to create a separate ImageService, as shown here, and let it do all the work:

    @Service 
    public class ImageService { 
 
      private static String UPLOAD_ROOT = "upload-dir"; 
 
      private final ResourceLoader resourceLoader; 
 
      public ImageService(ResourceLoader resourceLoader) { 
        this.resourceLoader = resourceLoader; 
      } 
      ... 
    } 

This last Spring service can be described as follows:

• @Service: This indicates this is a Spring bean used as a service. Spring Boot will automatically scan this class and create an instance.
• UPLOAD_ROOT: This is the base folder where images will be stored.
• ResourceLoader: This is...

With our reactive image service in place, we can start to work on the reactive file controller.

For starters, let's create a HomeController as shown here:

    @Controller 
    public class HomeController { 
 
      private static final String BASE_PATH = "/images"; 
      private static final String FILENAME = "{filename:.+}"; 
 
      private final ImageService imageService; 
 
      public HomeController(ImageService imageService) { 
        this.imageService = imageService; 
      } 

The preceding code can be described as follows:

• @Controller: This indicates that it is a web controller, and will be registered by Spring Boot to handle web requests.
• BASE_PATH: This is a static string used to define the base of many routes.
• FILENAME: This is a pattern for filenames where the "." is included. Otherwise, Spring...

At this stage, you've gotten a good taste of how to whip up a file-handling controller, and hitch it to a service that reads and writes files to disk. But the question that often arises is why do I need to do this reactively?

With imperative programming, the process of taking inputs, building intermediate collections and other steps often leaves us with lots of intermediate states--some of it potentially blocking in bad places.

Using the functional style as we've explored so far moves away from the risk of inefficiently building up this state, and switches to building a stream of data instead. And Reactor's operations let us have one stream feed another in lots of different ways. We can merge streams, filter streams, and transform streams.

When we engage in reactive programming, the level of abstraction moves up a level. We find ourselves...

Having put Thymeleaf on the classpath, an entire reactive view resolver has already been configured for us. The last step in putting together the web layer for our social media platform is to create the Thymeleaf template itself. We can do that by putting the following content into index.html underneath /src/main/resources/templates:

    <!DOCTYPE html> 
    <html xmlns:th="http://www.thymeleaf.org"> 
    <head> 
      <meta charset="UTF-8" /> 
      <title>Learning Spring Boot: Spring-a-Gram</title> 
      <link rel="stylesheet" href="/main.css" /> 
    </head> 
    <body> 
 
    <h1>Learning Spring Boot - 2nd Edition</h1> 
 
    <div> 
      <table> 
        <thead> 
        <tr> 
            <th>Id<...

Invariably, the question comes along--Do I need a synchronous or asynchronous API?

It's important to understand that reactive programming is not very effective unless the entire stack is reactive. Otherwise, we're simply blocking at some point, which causes the backpressure to not achieve much. That's a long-winded way of saying there is little value in making the web layer reactive if the underlying services are not.

However, it is very likely that we may produce a chunk of code that must be tapped by a non-reactive layer, hence, we have to wrap our asynchronous, non-blocking code with the means to block.

Let's explore async-to-sync by creating a BlockingImageService. This service will, basically, leverage the already written ImageService, but not include any of Reactor's Flux...

We're off to a good start by building the web layer of our social media platform. We used the Spring Initializr to create a bare bones Reactive Spring application with Gradle support. Then we explored the basics of reactive programming by creating a reactive image handling service and wrapping it with a reactive web layer. And we drafted a Thymeleaf template to show thumbnails, allow deleting of images and uploading of new images.

In the next chapter, we will see how to build a data layer and make it reactive as well.