Last Updated on August 25, 2024 by KnownSense
Before diving into the specifics of Project Reactor and Spring WebFlux, we recommend reading our detailed articles on Reactive Programming and Reactive Streams. These articles provide a foundational understanding of the reactive paradigm, essential for grasping the concepts discussed here. This article will build upon that knowledge to explore the powerful features of Project Reactor and how Spring WebFlux leverages them to create scalable, non-blocking web applications.
Project Reactor
Project Reactor is a library that implements all reactive stream specifications. It provides an extensive set of tools and abstractions that enable developers to do reactive programming. Project Reactor brings us two major components, types and operators.
The types introduced by Project Reactor are mono and flux. Other operators may be very familiar to you if you’ve previously worked with Java streams. Operators, such as map, filter, and flatMap, are also in the Project Reactor.
Project Reactor’s Types
A flux represents a flux of data that emits certain signals. When the connection between the publisher and subscriber is realized, an onSubscribe signal is emitted. Then, the publisher starts pushing events. First, it pushes a circle. When that occurs, another signal is emitted called onNext. Actually, every time the publisher pushes a new data item, an onNext signal is generated. Each onNext event contains the data item produced by the publisher. After all items are sent, the publisher can tell the subscriber it finished pushing all events by emitting an onComplete signal.
The mono type works in a similar fashion. When the subscriber connects to a mono publisher, an onSubscribe signal is emitted. The mono publisher then starts sending its data. In that moment, an onNext signal is emitted. However, here is the main difference between a mono and a flux. While using monos, we are certain that only one data item is sent before the onComplete signal is emitted. Mono comes from the ancient Greek, meaning one or single, so, while using monos, we are only receiving one data item, whereas with flux, we can receive more than one before closing the data stream.
But, what if something bad happens while the transfer is in progress? Let’s say our subscriber successfully connects to our publisher. The publisher manages to push a few data items, but then the network connection is interrupted. In this case, an onError signal is emitted. This helps us gracefully handle exceptional scenarios.
Spring WebFlux
Spring WebFlux takes advantage of all the concepts and components we discussed until this point and brings them to the Spring framework. In Spring we already have the Spring Web MVC framework. The Spring Web MVC framework is based on the Servlet API, a rather old specification that provides web capabilities in a blocking fashion. The need for non‑blocking capabilities pushed the Spring framework to adopt a new stack called WebFlux. Spring WebFlux is using Project Reactor under the hood, which evidently, is using the Reactive Streams specification and not the Servlet API.
But, how did we end up with this need? In the past, we dealt with monolithic applications, which required a minimal I/O interaction, mostly represented by connections to the database. Today, we are dealing with microservices architectures that perform a lot more network calls than a monolith. All these network calls are I/O operations that block code execution from the moment they start. By adopting a reactive approach, we are able to handle concurrency with a smaller number of threads and fewer hardware resources.
Conclusion
In conclusion, we’ve explored the key features of Project Reactor, including its different types and how they support reactive programming. We’ve also discussed the motivation behind the introduction of Spring WebFlux, which leverages Reactor to build efficient, non-blocking web applications, offering a modern alternative to traditional blocking web frameworks.