In a world that continues to evolve rapidly, the way we build software too is in a constant state of flux. The heavy architectures of yesterday have given way to new, lighter, more agile architectures such as reactive programming.
What Is Reactive Programming?
At its core, reactive programming is a way of defining inter-communications and codependent behaviors of program components, so that there is minimal interdependence..
In simple terms, this is achieved by each individual component exposing data about changes happening within them in a format and medium accessible to others, while allowing other components to act upon this data if it is of any relevance to them.
In today’s always-on, completely mobile world users expect responses in milliseconds, along with 100% uptime. Only systems that are responsive, resilient, elastic and message driven can deliver this kind of performance, which is why they can be termed ‘reactive systems’. And in order to build reactive systems, we must employ ‘reactive programming’.
How Did Reactive Programming Come To Be?
As a technique, reactive programming has been in existence since the seventies (and perhaps even before) and is not something that rose to prominence recently. For instance, when the Graphical User Interface (GUI) was first introduced, reactive programming techniques could have been used to reflect changes in the mouse pointer’s position on the screen.
Examples of Reactive Programming At Work
In general, reactive programming can be seen in action in the following instances:
- External Service Calls
Under reactive techniques, a developer will be able to optimize the execution of any external HTTP or REST calls, thus benefiting from the promise of ‘composability’ offered by reactive programming. - Highly Concurrent Message Consumers
Reactive programming can also be used in situations where messages need to be processed between multiple systems, a need that frequently arises in the enterprise space. The patterns of reactive programming are a perfect fit for message processing since events usually translate well into a message. - Spreadsheets
Often the favourite tool (or bane) of many cubicle dwellers, Excel is another perfect example of reactive programming at play. Think of a scenario where you built a model with interdependencies between several cells. A group of cells will be linked to one cell, or even another spreadsheet. Making a change in the precedent cell, will automatically force changes in the dependent cells. This is in effect, reactive programming at play.
When To Use Reactive Programming
In practice, programmers use both reactive and traditional techniques. As such, there is no definitive guide on when to use reactive programming and when not to. It’s more of an intuitive understanding, which a developer will gain over time through experience and countless hours of coding.
As a rule of thumb, if an application’s architecture is simple and straightforward, a developer may be better served by sticking to traditional code structuring methods. Breaking this rule may leave you with an over-engineered product on your hands, which is undesirable.
But, as with all things, proceed with caution. If you do end up following a reactive programming technique over imperative or some other technique, you will essentially be accepting a much higher level of code complexity, in return for more flexibility and robustness in the components of your program. Therefore, it is upto you to weigh the costs against the benefits.
The reactive landscape has evolved so much that today, we have Reactive UIs, ReactiveX APIs, and even Reactive microservices. Overall, these developments point towards a very bright future for reactive programming as a practice.
That wraps up our thoughts on the evolution of reactive programming.
What would you like to see us discuss next? Let us know in the comments below.
References