Another critical point that must be mentioned here is the inevitable changes in the Web module. First of all, Spring Boot 2 introduces a new Web starter called WebFlux, which brings new opportunities for a high-throughput and low-latency application. The Spring WebFlux module is built on top of the Reactive Streams adapter and provides integration with server engines such as Netty and Undertow, along with the support of ordinary Servlet-API-3.1-based servers. In this way, Spring WebFlux provides a nonblocking foundation and opens up new possibilities for Reactive Streams as a central abstraction for interaction between a business logic code and a server engine.
In turn, Spring WebFlux extensively uses Reactor 3 as a first-class citizen. Because of this, we can use reactive programming out-of-the-box without any additional effort, and we can also run a web application on top of the built-in integration of Project Reactor with Netty. Finally, the WebFlux module provides built-in backpressure support, so we can be sure that the I/O does not become overwhelmed. Apart from the changes in the interactions on the server-side, Spring WebFlux brings a new WebClient class that enables nonblocking, client-side interactions.
Furthermore, as well as the introduction of the WebFlux module, the good old WebMVC module also gained some support for Reactive Streams. Starting with the fifth version of the framework, the Servlet API 3.1 also became a baseline for the WebMVC module. This should mean that WebMVC now supports nonblocking I/O in the form proposed in the Servlet specification. However, the design of the WebMVC module has not changed a lot regarding the nonblocking I/O at the proper level. Nevertheless, the asynchronous behavior of Servlet 3.0 has been properly implemented there for some time. In order to fill the gap in reactive support, Spring WebMVC provides an upgrade for the ResponseBodyEmitterReturnValueHandler class. Since the Publisher class may be considered an infinite stream of events, the Emitter handler is the appropriate place to put the logic for reactive type handling without breaking the whole infrastructure of the WebMVC module. For that purpose, the WebMVC module introduces the ReactiveTypeHandler class, which takes care of properly handling reactive types, such as Flux and Mono.
As well as the changes that support reactive types on the server side, in order to get the non-blocking behavior on the client side, we may use the same WebClient taken from the WebFlux module. At first glance, this may seem to cause a conflict between the two modules. Fortunately, Spring Boot comes to the rescue and provides a sophisticated environment management behavior based on the available classes in the classpath. Consequently, by providing the WebMVC (spring-boot-starter-web) module along with WebFlux, we get the WebMVC environment and the nonblocking reactive WebClient from the WebFlux module.
Finally, when comparing both modules as reactive pipes, we get the kind of arrangement that is shown in the following diagram:
As we can see from the preceding diagram, in both cases of WebMVC or WebFlux usage, we get an almost identical Reactive Streams-based programming model. One of the notable differences between the modules is that WebMVC requires the blocking write/read at the point of integration with the Servlet API originating in the old module's design. This flaw leads to degradation in the interaction model within a reactive stream and downgrades it to the plain PULL model. In turn, WebMVC now uses a thread pool internally dedicated to all blocking reads/writes. Consequently, it should be appropriately configured in order to avoid unexpected behavior.
In contrast, the WebFlux communication model depends on the network throughput and underlying transport protocols that may define its own control flow.
To summarize, Spring 5 introduces a powerful tool for building a reactive, nonblocking application using the Reactive Streams specification and Project Reactor. In addition, Spring Boot enables powerful dependency management and autoconfiguration, thereby protecting us from dependency hell. We are not going to go into detail regarding the features of the new Reactive Web, but we will extensively cover the WebFlux module in Chapter 6, WebFlux Async Non-Blocking Communication.