Nowadays, the term reactive programming is trending. Libraries and frameworks in various programming languages are emerging. Blog posts, articles and presentations about reactive programming are being created. Big companies, such as Facebook, SoundCloud, Microsoft, and Netflix, are supporting and using this concept. So we, as programmers, are starting to wonder about it. Why are people so excited about reactive programming? What does it mean to be reactive? Would it be helpful in our projects? Should we learn how to use it?
Meanwhile, Java is popular with its multi-threading, speed, reliability, and good portability. It is used for building a wide variety of applications, from search engines, through databases to complex web applications running on server clusters. But Java has bad reputation too—it is very hard to write both concurrent and simple applications using only the built-in tools, and programming in Java requires writing a lot of boilerplate code. Also, if you need to be asynchronous (using futures, for example), you can easily get into “callback hell”, which actually holds true for all programming languages.
In other words, Java is powerful and you can create great applications with it, but it won’t be easy. The good news is that there is a way to change that, using the reactive style of programming.
What is reactive programming?
Reactive programming is a paradigm that revolves around the propagation of change. In other words, if a program propagates all the changes that modify its data to all the interested parties (users, other programs, components, and subparts), then this program can be called reactive.
A simple example of this is Microsoft Excel. If you set a number in cell A1 and another number in cell ‘B1’, and set cell ‘C1’ to SUM(A1, B1); whenever ‘A1’ or ‘B1’ changes, ‘C1’ will be updated to be their sum.
Let’s call this the reactive sum.
What is the difference between assigning a simple variable c to be equal to the sum of the a and b variables and the reactive sum approach?
In a normal Java program, when we change ‘a’ or ‘b’, we will have to update ‘c’ ourselves. In other words, the change in the flow of the data represented by ‘a’ and ‘b’, is not propagated to ‘c’. Here is this illustrated through source code:
int a = 4;
int b = 5;
int c = a + b;
System.out.println(c); // 9
a = 6;
System.out.println(c);
// 9 again, but if ‘c’ was tracking the changes of ‘a’ and ‘b’,
// it would’ve been 6 + 5 = 11
This is a very simple explanation of what “being reactive” means. Of course, there are various implementations of this idea and there are various problems that these implementations must solve.
Why should we be reactive?
The easiest way for us to answer this question is to think about the requirements we have while building applications these days.
While 10-15 years ago it was normal for websites to go through maintenance or to have a slow response time, today everything should be online 24/7 and should respond with lightning speed; if it’s slow or down, users would prefer an alternative service. Today slow means unusable or broken. We are working with greater volumes of data that we need to serve and process fast.
HTTP failures weren’t something rare in the recent past, but now, we have to be fault-tolerant and give our users readable and reasonable message updates.
In the past, we wrote simple desktop applications, but today we write web applications, which should be fast and responsive. In most cases, these applications communicate with a large number of remote services.
These are the new requirements we have to fulfill if we want our software to be competitive. So in other words we have to be:
Modular/dynamic: This way, we will be able to have 24/7 systems, because modules can go offline and come online without breaking or halting the entire system. Additionally, this helps us better structure our applications as they grow larger and manage their code base.
Scalable: This way, we are going to be able to handle a huge amount of data or large numbers of user requests.
Fault-tolerant: This way, the system will appear stable to its users.
Responsive: This means fast and available.
Let’s think about how to accomplish this:
We can become modular if our system is event-driven. We can divide the system into multiple micro-services/components/modules that are going to communicate with each other using notifications. This way, we are going to react to the data flow of the system, represented by notifications.
To be scalable means to react to the ever-growing data, to react to load without falling apart.
Reacting to failures/errors will make the system more fault-tolerant.
To be responsive means reacting to user activity in a timely manner.
If the application is event-driven, it can be decoupled into multiple self-contained components. This helps us become more scalable, because we can always add new components or remove old ones without stopping or breaking the system. If errors and failures are passed to the right component, which can handle them as notifications, the application can become more fault-tolerant or resilient. So if we build our system to be event-driven, we can more easily achieve scalability and failure tolerance, and a scalable, decoupled, and error-proof application is fast and responsive to users.
The Reactive Manifesto (http://www.reactivemanifesto.org/) is a document defining the four reactive principles that we mentioned previously. Each reactive system should be message-driven (event-driven). That way, it can become loosely coupled and therefore scalable and resilient (fault-tolerant), which means it is reliable and responsive (see the preceding diagram).
Note that the Reactive Manifesto describes a reactive system and is not the same as our definition of reactive programming. You can build a message-driven, resilient, scalable, and responsive application without using a reactive library or language.
Changes in the application data can be modeled with notifications, which can be propagated to the right handlers. So, writing applications using reactive programming is the easiest way to comply with the Manifesto.
In next article we will implement the reactive sum example described in te beginning with Java Rx and we will introduce it, so stay tuned!!
References:
Learning Reactive Programming with Java 8
By: Nickolay Tsvetinov
