Once the feature of web reactive programming was added in the Spring framework, most of us started comparing and wondering which one was better. There is nothing compatible, or even incompatible, between these two ways of programming. To end users, it's the result; only beneath the line, things will be different. How much do we, as developers, want to enhance the user experience and how much asynchronous support do we want to add will decide whether to use the traditional way of coding to deal with web request or to use new paradigm of programming called reactive programming. It's impossible to leave an existing application behind and start supporting only the new way. Spring web MVC on the Servlet 3.1 stack is still completely supported and, along with it, Spring web reactive is supported by Tomcat, Jetty, Undertow, and Netty-like Servlet containers.

The Spring Reactive framework, though based on the Reactor project, also supports the RxJava library to implement the functional reactive programming. Spring 5 is based upon the dependencies of Project Reactor 3.x. The following diagram shows how the collaboration is made between the APIs of Project Reactor, Spring, and ReactiveX:

Let's look at each of the components one by one:

• Reactive Core: This is the main library that provides the foundation for non-blocking Reactive Streams. It's an implementation of the Reactive Extension (Rx). It also provides support for passing on the messages.
• ADDONS: These add the support for RxJava1 as well as RxJava2 and enable the developers to use Observable, Flowable, Single, Scheduler, and many more reactive components.
• Inter Process Communication (IPC): This supports backpressure-ready components for encoding, sending, and decoding the messages. It also adds the support for Kafka and Netty.
• Reactive Stream Commons: This is a research-based project started as a collaboration in between Spring Reactor and Reactive Extension.

Now we know what the Spring Reactor is, let's now move on to how Spring supports reactive programming.

Spring 5 added the very new spring-webflux module to deal with reactive programming. The APIs are modified to facilitate @Controller, which is to be used to create controllers for non-blocking asynchronous programming. It is using the Servlet 3.1 non-blocking I/O, which can be run on the Servlet 3.1 container. ServletHttpRequest and ServletHttpResponse exposes Flux<DataBuffer> as the request and response body to allow reading and writing of the streams. The Spring MVC API is defined in such a way that it will be able to support the asynchronous and non-blocking I/O's.

We already discussed Spring MVC and the Spring RESTful application for its working, architecture, and handling request and response. We also discussed how the return types of the Spring MVC framework are supported and how to choose them. Now, as Spring supports reactive programming , we need to know how to add reactive data types in request or response. We can use the reactive types as discussed in the following scenarios:

• Mono<Book> book: This controller can use Mono after the book is deserialized
• Single<Book> book: This is similar to Mono, but uses the RxJava style
• Flux<Book> book: This is the input streaming accepting Flux
• Observable<Book> books: This inputs as per the RxJava style
• Book book: This Book is deserialized without blocking before the controller is invoked

Similarly, the response body can be used in any one of the following ways:

• Mono<Book>: This serialization will be completed without blocking the given book when Mono will be completed
• Single<Book>: The serialization will be completed without blocking the given book when Single will be completed; it uses RxJava
• Observable<Book>: This is also a streaming scenario, but it uses the RxJava Observable type
• Flowable<Book>: This is also a streaming scenario, but it uses the RxJava 2 Flowable type
• Flux<ServerSentEvent>: This is SSE streaming
• Mono<Void>: This is when Mono completes the request handling
• Flux<Book>: This is the streaming scenario
• Book: This serializes without blocking the given book
• Void: This request handling will be completed when the method returns, which is a synchronous, non-blocking controller method