Reactive programming (RP) is not something new and cutting-edge when it comes to application development. Chances are, you’ve already heard about it. The term was initially introduced to the IT world in the 1960-s and ever since much has been said and written in its regard. Unfortunately, as it often happens, the new concept quickly fueled a set of misinterpretations around itself, and still continues doing so today. The Reactive Manifesto of 2014 that introduced ‘reactive systems’ and their four ‘sacred principles’ messed everything up even more. So, let’s try to clarify what is what, and understand why and where we need reactive programming in Java application development (if we really do).
Reactive programming is a programming paradigm that deals with asynchronous data streams (sequences of events) and the specific propagation of change, which means it implements modifications to the execution environment (context) in a certain order.
Here’s a real-life example. Say, it’s Friday and John wants to spend this evening with his friend Bob, scarfing pizza and watching one of the Star Wars episodes. Let’s outline the options he has.
- John finishes his work. Then goes and orders the pizza, waits till it’s done. Then picks up his friend. And finally (with Bob and pizza) makes it home and gets down to the movie. It will be the sync approach and it will be way too long, so that probably John will have wanted to call the thing off by that time.
- John orders his pizza online, phones Bob, invites him to come. He heads home, has his pizza delivered and starts watching the movie (and eating the pizza) without waiting for Bob to show up. That is what can happen with the async approach.
- John orders pizza, phones Bob, invites him to come, heads home, and gets his pizza delivered. But this time, he waits until Bob comes and only after that he turns the movie on. This is what the reactive approach is about. You wait till all async actions (changes) are completed and then proceed with further actions.
No, they are not. Though often used interchangeably, the terms are not exactly synonymous and reflect different things.
Reactive systems represent the next level of ‘reactivity’. This level implies specific design and architectural decisions that allow building resilient, flexible, and responsive applications.
You don’t have to use reactive programming in reactive systems, but it’s a good idea to do so, as the combination brings even more benefits to your application, as make them even more loosely coupled, allow more efficient use of resources, make them more responsive and ensure lower latency.
When it comes to huge volumes of data or multi-userness, we often need asynchronous processing to make our systems fast and responsive. In Java, a representative of old object-oriented programming, asynchronicity can become really troublesome and make the code hard to understand and maintain. So, reactive programming is especially beneficial for this ‘purely’ object-oriented environment as it simplifies dealing with asynchronous flows.
With its latest releases (starting with Java 8), Java itself has made some attempts to introduce built-in reactivity, yet these attempts are not very popular with developers to date. But there’re some live and regularly updated third-party implementations for reactive programming in Java that help to save the day and thus are particularly loved and cherished by Java developers.
RxJava was the first Reactive Extension API specific for the Java platform. It works with Java 6 and provides an opportunity to write asynchronous, event-based programs for both Java and Android Java, which is very convenient.
Spring Reactor is another framework for Java from Spring developers. It is quite similar to RxJava but has simpler abstraction. The framework has managed to win popularity due to the possibility to leverage benefits of Java 8.
Increased performance – due to the possibility to handle huge volumes of data in a quick and stable way.
Improved UX – due to the possibility to keep the application more responsive to its user.
Simplified modifications and updates – due to more readable and easier to predict code.
‘Reactive’ components can be smoothly introduced to an application just as its part, so it’s unnecessary to change the whole project programming model, sabotage other trusted programming styles, cling to ‘reactivity’ completely and introduce unnecessary complexity. Measure is treasure. For example, if it’s just a simple web site – there’s hardly any need to write it reactive. But as soon as you want to upgrade it and introduce recommendation system – reactive code will be a good idea here to deal with the high load of big data.
Going reactive provides an elegant solution when it comes to specific types of high-load or multi-user applications:
- Social networks, chats
- Audio and video apps
And to the following components of any application type:
- Server code that serves highly interactive UI elements
- Proxy servers, load balancers
- Artificial intelligence, machine learning
- Real-time data streaming
Would like to see a real life example? Check our recent Java project where we applied reactive programming.
#9 When not to use RP?
Simply put, do not try to apply to RP where there is no need to, e.g. where there is no ‘live’ data, high load, or a large number of users who change data simultaneously.
Unfortunately, simply studying the theory and downloading the frameworks will have little impact. It takes a good amount of time, effort and practical experience for a Java developer to make the imperative mind get used to a different level of abstraction. That’s why, in case you decide to adopt ’reactivity‘, it is better to turn to a good consultant with true understanding of the approach who will be able to detect where reactive components would be a benefit for your system and how you can seamlessly introduce them in it.
‘Reactive programming’ is not a buzzword anymore but still not clearly defined. We hope that next time you come across this term it will not bewilder you as now you know that it’s just another coding style that centers on the effective management of changes with async data streams. RP is of particular importance for object-oriented Java where asynchronicity often results in the code that is hard to understand and maintain. RP can be challenging as it requires a Java developer to wrap the mind around a completely new programming style. However, in case of success, no efforts will be wasted as it allows applications to be more resistant to high load and greatly improves UX making them more responsive. Nevertheless, it’s also important not to overreact. The thoughtless use of the reactive approach with no real need will just ruin an application with unnecessary complexity.