Reactive Web Patterns

Reactive patterns and non-blocking programming techniques are widely extended technologies nowadays. However, when we focus on the web layer and exposed APIs, there is still a wide majority of applications that use blocking strategies.

Reactive approach vs. other web approaches

To clarify how this new reactive web approach differs from other ones, let’s compare it with two existing techniques:

• The Servlet 3.0 specification introduces asynchronous support, which means you can optimize the use of container threads using Callable and Spring’s DeferredResult as a response from controllers. However, from the client’s perspective, they’re still blocking calls. Besides, the imperative way of using the API is far from being developer-friendly, so they are seldom used.

• From the web client’s point of view, you can rely on asynchronous patterns as well. This is the most popular way of performing a request to the server, using promises. Clients usually perform requests and wait for the response in different threads so that the main flow doesn’t block. The response arrives in the background, and then a callback function processes the data and has the ability to, for example, update the HTML’s DOM. Again, even being asynchronous, the additional thread is also blocked, waiting for a response that might take a long time to complete, and receiving all the data at once.

In a reactive web approach, threads don’t block until all the data is available. Instead, every layer is capable of providing data as soon as they process it. Therefore, web clients can start doing their part sooner, and we improve the user’s experience. It is also more efficient since the different layers can process information in a continuous stream instead of being idle until a whole chunk of data arrives.