Presentation: Servlet vs Reactive Stacks In 5 Use Cases

​Rossen: Last year at QCon New York I presented "Intro to Reactive Programming" based on my own experience with building a reactive web framework for Spring Framework 5.​ This year my goal is to use sample code with HTTP endpoints to compare the execution models of a distributed application running on the Servlet API + Servlet container stack to that of an application running on a Reactive Streams + Netty stack. Thanks to the reactive support in Spring Framework 5 we can take a Spring MVC annotated endpoint (with a flexible method signature) and in many cases run the same as a Spring WebFlux (the Spring 5 reactive web framework name) endpoint and then reason about the differences. Note however that this isn't about Spring nor is knowledge of Spring required. It is about understanding the impact of non-blocking and reactive on Java web applications.

To make matters more interesting Servlet vs Reactive is not as black or white as it might sound. Servlet has a non-blocking API which can be bridged to Reactive Streams so you can be fully reactive on Tomcat or Jetty. Furthermore in Spring 5, the Servlet-based Spring MVC provides first-class support for using reactive client libraries such as an HTTP client or a reactive data repository.

There are plenty of existing applications that cannot change immediately and many arguably don't have a strong rason to change. This is why it's important to have a clear and evolutionary path of migration as well as to understand the trade-offs.

Rossen: The main target audience is Java web application developers with some experience in running and scaling applications on Servlet containers (e.g. Tomcat, Jetty) including an understanding of the Servlet container execution model. Non-Java developers as well as non-developers can also benefit from the concepts presented in the talk. These concepts represent important trends in the Java ecosystem. Knowledge of using reactive libraries (e.g. RxJava, Reactor) is helpful but not required.

Rossen:

• Use reactive libraries in classic Servlet ​container + Servlet API stack web applications
• Go fully reactive and event-loop driven in Java with Spring 5 and Spring Boot
• Understand the ​differences in execution models and explain the benefits of the reactive approach

Generally speaking yes, the Servlet API was originally created for a synchronous and imperative programming model. Some improvements have been made over time such as Servlet 3.0 async requests that allow for request handling code to become fully reactive with no cost to the Servlet container. Others such as the Servlet 3.1 non-blocking I/O go farther but they can't be used without leaving the rest of the Sevlet API behind. The goal of this session is to illustrate the differences.