DEV Community

Cover image for Reactive vs Servlet Stack
Germano Schneider
Germano Schneider

Posted on

Reactive vs Servlet Stack

Introduction

Are you wondering what is the best stack to use when creating a new Spring Boot application? Well, if you don't have an answer, I believe I can help you through this article. First, let's establish that the goal of a stack is not to replace another, but to serve it's own unique purpose.

Let's take a look at the main differences between the Reactive and Servlet Stack as well as the ideal uses of each one.


What is a stack?

In the context of a Spring application, a stack is a resource package that determines the specific architecture, framework, etc. that an application requires. The Spring Framework has two different stacks:

Image description


Servlet Stack

This is a classic! It was created by Spring and is the most commonly used by developers around the world. It supports some Servlet Containers such as Tomcat, Jetty, and Undertown. For this stack, we develop our code with the Spring MVC Framework.

Synchronous and asynchronous calls can be used, but with the blocking/IO architecture. For every request, the user must wait for a response before proceeding. This model works over a thread pool, which is always incremented when there is a huge API call traffic. Consequently, you will have high hardware consumption when there is a large number of requests.

Image description


Reactive Stack

After some years, the Spring Framework 5 released the Reactive Stack. The objective of this stack was to allow the Spring applications to have a higher performance during huge traffic data and large concurrency. But how does it do this? The Reactive Stack possesses new features such as non-blocking/IO architecture, Servlet Container 3.1, Netty Server, Spring WebFlux Framework, etc. It operates on a 'less is more' principle, as it can attend to large concurrency utilizing fewer hardware resources.

Image description


What stack should I choose for my Spring application?

The anwser depends on your needs. When designing your application, you must ask yourself (or your team) some questions, such as:

  • How many requests am I waiting for?

  • Do I have a team prepared to work with this?

  • What is my budget?

Finding new professionals with extensive experience in reactive programming can sometimes be challenging. As a result, some companies may opt for alternative strategies or technologies that incur lower operational costs.


Reactive vs Servlet Stack

Let's reiterate that the purpose of these stacks is not to eliminate the other but to attend to specific needs.

  • Learning Path

The Servlet Stack caters to what developers are accustomed to developing presently, which is imperative code. It is easy to write, read and debug. In constrast, the Reactive Stack uses funcional programming, which requires a deeper understanding and the implementation of a more complex code.

  • Execution Model

There are two different execution models: The Reactive Stack applies an Event Loop, similar to NodeJS. It has the capacity to handle many requests from the client with only a few threads. All requests are processed in an event queue. When a new request is received, the thread is released and a callback is always registered. For the Servlet stack, however, we implement the Thread per Request Model to handle requests. This model works over a thread pool, blocking each incoming request on the Servlet API. Once the thread’s number runs out, we must wait until one of them is released. There is a significant amount of hardware resource consumption with this model.

  • Non-Blocking/IO vs Blocking/IO

The Blocking/IO is an architecture type utilized on the Servlet API. Although we are able to execute asynchronous operations with Spring MVC, it is limited when a request arrives at the Servlet API because the server will block all completed remote calls. The Reactive Stack brought the Servlet API 3.1 and the Netty Server, which both support Non-Blocking/IO processes, removing the need for the final user to wait for a response.


Conclusion

This was a short theoretical article written with the intention of emphasizing the importance of distinguishing between both Spring Stacks. Be mindful of data traffic volume as well as concurrency within the application when creating a new Spring application. This is crucial when reducing the cost and number of resources consumed.


References

Spring Conferences:

Official Documentation:

Top comments (0)