Industry buzzwords like ‘Microservices’, “Reactive” and “Functional” are obviously not new to the software industry as professionals have been using them to analyze the problems common to many enterprise organization applications.

Here, I will elaborate why to go for reactive programming.

Understanding the question is half the answer; so let’s first discuss the traditional approach of any service or more specifically a web service.

SIDE NOTE: Going on, you will hear words like ‘blocking’ or ‘asynchronous’ but please remain in your seats as I will be describing each one of them.

Don’t worry, I am with you!!

Sorry. That came out wrong.

Anyways…

A Quick Overlook at the old approach

Traditionally,

1. A server (service provider) runs on a ‘daemon thread’ listens on a given port. (Daemon thread: The main process thread currently in use and “held” by the server).
2. A client sends a request to the server.
3. The server uses the main ‘daemon’ thread to serve the response.
4. It does the necessary computations (Calling other services, database queries etcectra).
5. It prepares and returns the response to the client.

Right now, you might be thinking about why the daemon thread is on hold all that time? That’s fascinating because I have read your mind.
If you were not thinking that, you are now.

In either case, I have the ability to read and manipulate your mind.

Just kididng 🙂

Or am I ?

Well…

The “demon” (Something evil that crawls under your bed at night) is holding the main thread throughout the whole frigging request process. Doing this will affect other clients waiting for the server to respond.
This approach is called the blocking approach which results in a lot of clients waiting for the response ultimately affecting the overall service response.
Although it’s only a matter of seconds, but it matters when it comes to computers, servers and all sorts of that sh*t. (1 second = 1 thousand milliseconds)

Reactive to the rescue

Instead of blocking the daemon thread and waiting for the completion of computations, the application will be using the available resources asynchronously to perform the heavy tasks on separate threads.

Also, non-blocking applications are written using a methodology that thread never block – this means whenever a thread has to block on an I/O operation (e.g. reading from a socket), it instead gets notified (by an event or message) when new data is available (This is the reason for the term ‘reactive‘). How that is implemented is OOS(Out Of Scope) for this post. Due to this, we use the term asynchronous which is also used as a synonym for non-blocking in a lot of scenarios.

In short, the main thread will be released immediately after receiving a request.

There, if multiple requests are made to your web app (the web app reads some data from the db and responds), the tool(spring, node etc) reads the input from each socket (gets notified by each socket for each request), and when everything is read, it generates a “new request” event to the application code base. The application code then generates an event addressing the database access layer, which sends a message to the database using the specified reactive driver, and gets an event whenever reading the data from the database is complete. When all the processing is finished, there is a callback to the caller of the application (maybe a frontend controller), which writes the response data, by sending it as event(s). All this is done using a lot of events/ messages.

Since the new request will be processed by other threads so the main thread is available to listen to other clients.

All these buzzwords ‘reactive’, ‘asynchronous’, ‘non-blocking’, ‘message-driven’, ‘event-driven’ go together the buzzword-driven marketing jargon. See the joke ? 🙂

The Value

In a production environment where we have thousands of clients and heavy computations to be done by the server, the decrease in the response time even by a few milliseconds significantly improves the user experience.