Spring MVC versus WebFlux

Spring WebFlux was brought in as part of Spring 5 to bring in a new alternative to existing Spring MVC. Spring WebFlux brings in non-blocking event loop style programming to provide asynchronicity.

Event loop was brought in and made famous by Node.js. Node.js was able to perform non-blocking operations using single-threaded JavaScript by offloading operations to the system kernel whenever possible. The kernel, being multithreaded, is able to do these offloaded operations and after successful execution notifies Node.js through callbacks. There is a constantly running process that checks the call stack (where operations are stacked which need to be executed) and keeps executing processes in First In, First Out (FIFO) manner. If the call stack is empty, it looks into the Event Queue for operations. It picks them up and then moves them to the call stack to be further picked for execution.

The following diagram shows what is in both web application frameworks:

Figure 1: Spring MVC and Spring WebFlux

As shown in the preceding figure, Spring MVC is based on the Servlet API (works on thread pools) and Spring WebFlux is based on reactive streams (it works on an event loop mechanism). Both the frameworks, however, supports commonly used annotations such as @Controller and also support some well-known servers.

Let's see the workings of Spring MVC and Spring WebFlux side-by-side in the following diagram:

Figure 2: Working of Spring MVC and Spring WebFlux

As you can see, the fundamental difference between the working of the two frameworks is that Spring MVC is blocking and Spring WebFlux is non-blocking.

In Spring WebFlux, Servlet APIs behave as an adapter layer, enabling it to support both servlet containers such as Tomcat and Jetty and non-servlet runtimes such as Undertow and Netty.

Spring MVC comprises synchronous APIs (Filter, Servlet, and so on) and blocking I/O (InputStream, OutputStream, and so on) as against Spring WebFlux's asynchronous APIs (WebFilter, WebHandler, and so on) and non-blocking I/O (Reactor Mono for 0..1 elements and Rector Flux for 0..N elements).

Spring WebFlux supports various asynchronous and Reactive APIs, namely Java 9 Flow API, RxJava, Reactor, and Akka Streams. By default, it uses Spring's very own reactive framework, Reactor, and it does do its job quite well:

Figure 3: Spring WebFlux reactive API support

As mentioned earlier, Spring WebFlux was brought in as an alternative to Spring MVC. It doesn't mean in any way that Spring MVC is deprecated. Applications written in Spring MVC can continue running on the same stack without any migration to Spring WebFlux. If needs be, we can bring in reactive coding practices to an existing Spring MVC application by running a reactive client to make calls to remote services.

Now that we have seen the features of the two web application frameworks in Spring, the next section will give an idea as to when to choose what framework while building your application.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.82.4