In this chapter, we learned that WebFlux is an efficient replacement for the good old Web MVC framework. We also learned that WebFlux uses the same techniques for request handler declarations (using the well-known @RestController and @Controller). In addition to the standard handler declaration, WebFlux introduces a lightweight, functional endpoint declaration using RouterFunction. For a long time, modern reactive web servers, such as Netty, and non-blocking Undertow features were unavailable to users of the Spring Framework. With the WebFlux web framework, these technologies have become available using the same, familiar API. Since WebFlux is based on asynchronous non-blocking communication, this framework depends on Reactor 3, which is the core component of the module.
We also explored changes that have been introduced with the new WebFlux module. These include changes to communication between the user and the server, based on Reactor 3 Reactive Types; changes to communication between the server and external services, in particular with the new WebClient technology; and a new WebSocketClient, which allows client-server communication over WebSocket. Also, WebFlux is a cross-library framework, which means that any Reactive Streams-based library is supported here and may replace the default Reactor 3 library or any other preferred library.
After that, this chapter introduced a detailed comparison of WebFlux and Web MVC from different perspectives. To summarize, in most cases, WebFlux is the right solution for high-load web servers, and in all performance results, it performs twice as well as Web MVC. We looked at business gains of using the WebFlux module and considered how WebFlux simplifies work. We also looked at the pitfalls of this technology.
Finally, we learned about a few use cases in which WebFlux is the most appropriate solution. Those cases were microservice systems, real-time streaming systems, online games, and other similar application areas, where the important characteristics include low latency, high throughput, low memory footprint, and efficient CPU utilization.
Although we have learned about the core aspects of the web application, there is another even more important part, which is interaction with databases. In the next chapter, we will go through the main features of reactive communication with databases, which databases support reactive communication, and what we should do when there is no reactive support.