Understanding Spring Reactive: Introducing Spring WebFlux

In this article, we are going to discuss the different choices provided by Spring 5 for the Reactive and Async concurrency model. I strongly believe that, before we embrace something new, we should be aware of the differences between choices and how it connects to what we have been already doing. In my previous articles on this topic, I have tried to explain what we already have regarding the concurrency model and how the concurrency model has changed in Spring over the years, with several updates in Servlet APIs. I would strongly recommend reading my previous articles on this topic so that this article will make more sense!

Let’s try to figure out what was the reason to provide two different non-blocking stacks in Spring 5. Basically, Spring 5 provides the following two stacks for doing things in Async and a non-blocking way:

1. Spring MVC (Servlet Stack)
2. Spring WebFlux(Reactive Stack)

Spring MVC (Servlet Stack)

With the introduction of Servlet 3.1, Spring MVC could achieve non-blocking behavior. But, as the Servlet API contains several interfaces that are still blocking (maybe because of support for backward compatibility), there was always the chance of accidentally using blocking APIs in the application, which was intended to be developed as non-blocking. In such scenarios, the usage of a blocking API will certainly bring down the application sooner or later. Let’s discuss one such scenario with the code snippet below:

void onWritePossible(){
  try{
     //some logic here
  }catch(Exception e){
     response.sendError(500); ----> sendError() is a blocking API
  }
}

To explain the above code in Spring MVC context, using the container-managed error page is blocking. Let’s take a look at the code on my GitHub repository.

@Controller
public class MyErrorController implements ErrorController {
    @RequestMapping(path = "/error")
    public String greeting() {
        return "myerror";
    }
    @Override
    public String getErrorPath() {
        return "/error";
    }
}

Whenever an error occurs in a Spring application, the container would invoke the  /error  page, and the ‘myerror’ page would be rendered in a blocking way. Off course, we have ways to handle such things, but they are definitely error-prone. To summarize, this is error-prone, because the application has access to the Servlet object, which has both blocking and non-blocking operations as shown below:

Flow Of Events

So, even though we have ways in Spring 5 MVC to write completely non-blocking code, the need was felt to have a stack in which there are no chances that an underlying, blocking API could be used. This means that the Servlet API is not directly exposed to the application. This forces us to incorporate the Spring Reactive stack, i.e. Spring WebFlux.

Spring WebFlux (Reactive Stack)

Spring WebFlux is a completely non-blocking reactive framework, and it is indeed different than what we have in Spring MVC. So, what does it take to not block in the Spring WebFlux:

• Event Loop at the core.
• Event-driven architecture, message passing
• Means to compose Async logic through the Reactive Streams API
• Backpressure

As we can see in the diagram below, Spring WebFlux does not directly use the Servlet. Instead, it uses the Spring Web API, which includes Reactor Streams.

The purpose of this series is to demonstrate the evolution of the Servlet/Spring from the blocking to non-blocking paradigm. I am not going into the details of Spring WebFlux in this tutorial. But, still, I am going to introduce a sample Spring Boot application using Spring WebFlux.

One point which we should notice in the above diagram is that Spring WebFlux is Servlet Container agnostic. Spring Webflux works on Servlet Container and also on Netty through Reactor Netty Project.

In my Spring boot application, I have a dependency on WebFlux as spring-boot-starter-webflux, and at server startup, it says that the application is ready with Netty.

[reactor-http-nio-1] 18:33 BlockingNettyContext: Started HttpServer on /0:0:0:0:0:0:0:0:8080

[restartedMain] 18:33 NettyWebServer: Netty started on port(s): 8080

In the same application, if we use dependency for the spring-boot-starter-web, then logs would be printed as shown below:

[restartedMain] 23:56 TomcatWebServer: Tomcat started on port(s): 8080 (http) with context path ''

So, without any code change, we can run the Spring WebFlux application as a Spring MVC application. But, vice-versa is not true as the Spring MVC application could be using the  HttpServletRequest/Response, which is not available in Spring WebFlux runtime.

I have created the same type of service that we used in an earlier article with WebFlux, as shown below:

@GetMapping(value = "/reactiveService")
public Mono<String> reactiveService(){
    logger.debug("reactiveService Request processing started");
    return webClient.get().uri("/sleep/1000")
            .retrieve().bodyToMono(Boolean.class)
            .doOnNext(response->{ logger.debug("reactive service");})
            .then(Mono.just("reactiveService"));
}

I would leave this for readers to compare the performance between this API and the  asyncNonBlockingRequestProcessing API, as both are using the non-blocking paradigm, but the underlying stack is different for both APIs.

Thank you for reading my article, and I hope it helps a bit in understanding Reactive in the Spring/Servlet context.

The source code for this post can be found on GitHub.