Rossen Stoyanchev, a Spring Framework committer at Pivotal, presented "Servlet vs. Reactive: Choosing the Right Stack" at QCon San Francisco 2017. Spring Framework 5 introduced a brand new reactive web framework spring-webflux, which resides alongside the traditional servlet based web framework spring-mvc. In his presentation, Stoyanchev talked about the differences in these two frameworks' execution models, and how to decide when to select spring-webflux over spring-mvc.
Stoyanchev said that reactive programming is about bringing asynchronicity in applications. Traditionally, in Java, developers have used threads and thread pools to bring asynchronicity in applications, but that approach is not efficient and does not scale well. There are a number of different approaches and solutions that are being advanced in different languages and platforms.
Stoyanchev notes that a general misconception in Java is that in order to make anything concurrent, one needs a large number of threads, which in reality is not the case. One can achieve concurrency in Java with a few fixed number of threads by using HTTP sockets and pushing chunks of data at a time through the sockets. This mechanism is called event-loop, the idea made popular by Node.js. Such an approach is scalable and resilient. Spring 5's spring-webflux uses the event-loop approach to provide asynchronicity.
According to Stoyanchev, Java 8 lambdas, one of the motivations for creating spring-webflux, put functional programming within reach and creating possibilities for doing new things, and processing requests in different ways.
Stoyanchev says the introduction of spring-webflux in Spring Framework does not mean that the servlet based spring-mvc framework will get deprecated in the coming future. Spring-webflux is intended to provide an alternative to spring-mvc. A lot of applications currently use spring-mvc and they may not have any good reason to switch to spring-webflux. Moreover, not all applications are a good candidate for spring-webflux.
The main difference between the two frameworks is that spring-mvc is based on thread pools, while spring-webflux is based on event-loop mechanism. Both the models support commonly used annotations such as @Controller.
A developer can run a reactive client from a spring-mvc controller to make calls to remote services. Spring-webflux supports servlet containers such as Tomcat or Jetty. It also supports non-servlet runtimes such as Netty and Undertow.
According to Stoyanchev, back in 2009, Spring 3.0 introduced async support for the servlet api, which meant that for a long running process, the thread could be released back to the container and response could be written once the process finished. This feature made it possible to support running reactive client in spring-mvc based application.
In spring-webflux, the servlet api is there as an adapter layer, which enables support for servlet based containers in addition to non-servlet containers.
Stoyanchev says that in spring-webflux, WebFilter and WebHandler are non-blocking. These methods return a Mono<void> which is a promise type in Reactor. Mono<void> contains information about the completion or failure of the process.
Spring-mvc supports a reactive client but once the processes reach servlet api, they work in blocking mode.
In conclusion, Stoyanchev suggests caution while choosing between spring-mvc vs spring-webflux. If the current application is running fine on spring-mvc and if there are no issues that call for a change in the stack, Stoyanchev suggests that one should stay with spring-mvc. He also suggests that it is a good idea to think about application dependencies. If the application has blocking dependencies then perhaps it is better to stay with spring-mvc stack.
A developer can still take advantage of reactive features by writing reactive clients in spring-mvc controller to make remote service calls, retrieve reactive data, and do response streaming.
Spring-webflux is a good fit for uses cases that require ease of streaming up or down. It should also be considered for applications where scalability and high efficiency are major considerations.
According to Stoyanchev, spring-webflux is not necessarily faster but it is better in dealing with the issues of scalability and efficient use of hardware resources. It is also better at dealing with the issues of latency.