What Does it Mean to Be 'Reactive?'
What Does it Mean to Be 'Reactive?'
What does it actually mean to be reactive? Click here to learn more about implementing a reactive system for your projects.
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
Currently, reactive is one of those trendy buzzwords in programming. Reactive is a word widely used as a prefix for “system” and “programming,” which both describe very different matters.
However, as an IT consultant and reactive sponsor, I have had a lot of experience and conversations surrounding reactive, but essentially, the main question is always the same:
What does reactive mean?
And, immediately after:
Why should I use reactive?
Even though there are a lot of articles that attempt to explain — in an exhaustive way — the reactive system, reactive programming, and/or both the above questions, these questions still persist.
As mentioned above, the reactive system is not the same thing as reactive programming. Moreover, concerning the reactive system, the reactive manifesto states that a reactive system pays closer attention to classic concepts of a “distributed system” that are based upon the “message-driven” architecture (ie. the reactive system is an architectural style).
After that, the question has been moved on to reactive programming and, more specifically, how the reactive framework deals with asynchronous execution and the (famigerate) threads.
Here, the problem has become a little bit more complex. These questions were based around different execution environments' implementation of the message loop and how it works, for instance, in node.js rather than in JVM.
To answer these questions, I’ve decided to draw a simple comic using a restaurant metaphor that I discovered surfing the online reactive sea that I’ve named the "Reactive Serving." Let's take a closer look.
Let’s imagine that you just became the owner of a little restaurant that only has a few tables (three, for example), and you have to hire an entire staff. What are your choices? Assuming that you only need one chef, how many waiters do you need to hire?
In this first approach, let’s try to solve this problem by using a classic (non-reactive) execution environment that only sponsors one-thread-per-request. Take a look below:
This solution looks interesting, especially if we want to suggest our restaurant as a local favorite, but meanwhile, we have to take into consideration the costs (number of waiters) and the fact that, the majority of the time, waiters do nothing.
On a scalability note, it is easy to understand that if you want an increasing number of tables in your restaurant, you have a linear increase in cost and resource needed.
Let's take a step back from this metaphor. By substituting the waiters with threads, the chef possesses the processing capability and the customer requests that we obtain. This includes what happened inside a classic execution environment where each thread is dedicated to a single request.
Now, let’s try to solve this problem using a different approach to the reactive execution environments that sponsor the single-thread-event-loop. Take a look below:
In the image above, we demonstrate one waiter for all customers — one thread for all requests. This approach assumes that we have one “reactive” waiter that works hard and asynchronously to satisfy the need of all customers interacting with the chef.
This solution probably looks less fascinating from the previous one, but it is absolutely more efficient because it contains lower costs and uses the maximum capability of your waiter. Therefore:
The more “reactive” the waiter and chef … the more effective your service is!
A quick note on scalability: if you want to increase the number of tables in your restaurant, you have to understand how reactive your waiter is, and if you need another one, you’ll need search for another reactive waiter. This means that the required costs and resources depend on your ability to manage such issues.
Now, let's take a step away from the restaurant metaphor. While thread plays the role of the waiter — the processing capability of the chef and customer of the request—, you (as owner) play the role of the system resource manager
The question is, in your case, which service model will you choose for your restaurant? Approach 1 or 2?
I hope that metaphor helps you understand how the reactive framework deals with asynchronous execution and the threads.
While a non-reactive system tries to manage resources using a predictive model (max number of threads, max number of requests per time), the reactive system relies on system capacity involving fewer resources that are better used, making the overall throughput of the system unpredictable (for that, we have to use empiric approach).
Enjoy the reactive world!!
Published at DZone with permission of Bartolomeo Sorrentino . See the original article here.
Opinions expressed by DZone contributors are their own.