Spring MVC versus Spring WebFlux

Spring MVC has been part of the Spring Framework since version 2, and since then, has been a de facto standard when developing web-based applications with Spring Framework. To support Reactive Programming, Spring has introduced the WebFlux module. Therefore, it is important to understand the similarities and differences between Spring MVC and Spring WebFlux.

The Spring team has done it the hard way and kept the WebFlux syntax similar to the Spring MVC, but under the hood it has completely new technology. One of the prime differences between these two modules is the mechanism by which they handle the request. Spring MVC is based on a pure servlet API and works with a thread pool. This means that, every request has one thread from the controller to the persistence layer and may be blocked for the resources it needs.

However, Spring WebFlux is based on reactive architecture and works with the event loop mechanism, providing non-blocking support out of the box. In the event loop mechanism, everything happens as a reaction to the event. It is similar to a callback function; when any event happens, the callback function gets triggered. The concept event loop was introduced by Node.js.

Internally, WebFlux needs servlet API support, which works as an adapter layer, so that WebFlux can be deployed on both servlet and non-servlet containers. Spring MVC is built on top of a servlet API, which is synchronous (like Filter, Servlet, and so on) by nature and also performs blocking IO streams.

WebFlux, on other hand, is developed on asynchronous API (WebHandler, WebFilter, and so on) and non-blocking IO mechanisms, like Flux and Mono , which are used to handle the stream with a maximum of one value and many elements, respectively. Although Spring WebFlux is based on reactor and used by default, it also supports other reactive implementations, like Java 9 Flow API, RxJava, and Akka stream. 

Both the frameworks, however, support some common features like using some annotation (like @Controller and @RequestMapping) and support for some well-known servers. 

We are talking about Reactive Programming support in String with WebFlux; it does not mean Spring MVC is of no use. Both frameworks are addressing separate concern to the application. Like any framework, WebFlux may not be the best choice for all the application types. 

So instead of choosing the framework by its features, you need to select it as per the requirement. There is absolutely no need to port your existing Spring MVC application completely to WebFlux if it is working perfectly well. The excellent part of WebFlux is that it can be used in conjunction with Spring MVC (if needed explicitly) without any problems. 

Apart from this, if your existing Spring MVC application has a dependency on other parts that are synchronous and blocking in nature then, adapting WebFlux specific changes will obstruct from taking full benefits of reactive paradigm. You can decide, however, to pick WebFlux if your application is mainly handling the stream of data. If scalability and performance are what you are looking for then you can use WebFlux specific changes in your application.