Why Reactive Is Here to Stay
Let's briefly analyze Reactive programming, touching on the doors it opens to non-blocking programming, and look at some tips for implementing it.
Join the DZone community and get the full member experience.Join For Free
Nowadays, we all are being bombarded by the latest trend of the moment: Reactive. Just to mention some examples, we can see Java and Spring moving their products in that direction. For that reason, we should check a scenario where Reactive can be helpful.
Although blocking and non-blocking approaches are not competitors, there will be always a discussion about which one provides more benefits while programming.
Blocking vs. Non-blocking
Let's start describing and focusing on the blocking approach.
As it has been for several years, and simplifying in order to make it understandable, when a service receives a request, a thread from the thread pool is assigned to that request, and when the business logic gets completed and the output is sent back, this particular thread becomes available again for another request.
This approach provides the ability to accept a certain number of requests, the limit being the number of threads.
Moving to the Reactive approach, and again simplifying the process, one thread will be responsible for dispatching tasks among remaining available threads (n-1). This will mean all requests will be accepted and served as soon as it business logic is completed.
The Key Role of Reactive
Nowadays, we are working with autoscalable machines in our infrastructure. The combination of autoscalability and non-blocking helps us to deal situations when our machines are working at their maximum performance and we need some time to create new ones.
When an unexpected situation brings us to a scenario when we're suddenly dealing with an exaggerated amount of traffic, autoscalability and non-blocking allow services to keep accepting requests while our other instances get ready to start receiving traffic. Of course, the response time will be affected, but at least they will be accepted and processed.
But keep one thing in mind, if you choose a Reactive approach, it must be from end to end. If you set a blocking piece of code inside your non-blocking service, it will not be non-blocking anymore.
When the community makes a move, it is always important to take into account. In this post, we analyzed Reactive programming and how it could help us deal with unexpected events, such as a scenario where we receive an exaggerated amount of traffic.
Opinions expressed by DZone contributors are their own.