Per Wikipedia, “Reactive Programming is a declarative programming paradigm concerned with data streams and the propagation of change.” This concept has existed in the market for some time. Being a developer you may have already implemented this methodology knowingly or unknowingly.
In this blog, I will cover the basic concepts related to reactive programming methodology and its implementation in Mule Runtime. Now, let’s get started!
Whenever the complexity of a project and it’s source code increases, we usually follow the concept of modularity to develop the systematic codes. Modularity refers to the concept of making multiple modules first and then linking and combining them to form a complete system. In simple words, modularity is nothing but dividing the functionality of code to make it reusable.
Here we come up with two approaches:
- Passive Programming.
- Reactive Programming.
You may also like:
5 Things to Know About Reactive Programming.
To understand this more effectively, let’s take a look at a use case. Let’s take an example of an ECommerce system in which different fields are there that can manipulate each other. Here, we have some common modules that are usually available in every E-Commerce system.
Let’s take an example Cart module and Invoice module from the above diagram and try to explore different approaches in development.
Usually, we have to create one update invoice and publish that method so that the Cart can modify its values. The Cart has some methods that are used to update the Invoice. Here, the Cart module is operating the entire modification process. So, we will import the method from Cart into our invoice. This is a Passive programming approach.
But, we have another solution for this also.
Instead of creating the method inside the invoice and making it public, we can define the same functionality inside the Cart. So, the Invoice will import the incrementing method of the Cart as follows:
Now, the cart is not operating any operation, it’s simply acting as a broadcaster. If any product gets added to Cart, it will get reflected to the Invoice directly. In layman’s terms, if I want to update the “Invoice,” I should write that code inside Invoice only. This is a Reactive programming approach.
Pros and Cons of Reactive Programming
You may think that there is no change, both are relatively the same. But imagine you are in a Support Project where the main coding is already done and you have that code with you. In the Passive approach, to analyze the code of ‘Invoice’ you have to check out each and every method and module that imports and manipulate the invoice.
But, in the case of a Reactive one, your task will be much simpler, as you are defining the functionality inside “Invoice” only. You can also partially compromise with the modularity of the entire code while going with a reactive approach.
We have to develop the code as follows:
Here, we have achieved the functionality of modularization (for reuse of code), along with a self-explanatory feature.
How to Identify if a System Is Reactive
As per the Reactive Programing Manifesto, “The system is called a ‘Reactive System’ when it is has 4 attributes.”
- Responsive: Responsive means quick and efficient by nature. If one can say the system is responsive, it means that he/she is referring to a fully functional system that provides rapid and stable response under passive loading.
- Resilient: The failure of the system is caused by bad user input. One’s system is “Resilient” when that system is capable of handling every failure, any bad input, or anything that makes it crash. In this case, we design the system in such a way that, the main working unit and failure handling components are different. Due to this methodology, we can easily achieve understanding of the system.
- Elastic: The ‘Elastic’ terms means that the system will perform efficiently irrespective of the load. The System will work efficiently in both cases, in full loading and in partial loading. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them.
- Asynchronous Messaging: One’s system may rely on asynchronous messaging when implementing the concept of non-blocking. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead. In other words, it should support non-blocking methodology (the concept of smooth execution of components).
How Mule Runtime Is Reactive?
As we now know, the Reactive Programing Manifesto defines the reactive system. The desirable properties of any reactive system are listed above. When we observed our Mule Runtime, we found that the above properties, like support support for asynchronous messaging, Elasticity, and Error handling are already available in it. That is why we can say that Mule ESB follows the reactive approach for development.