Reactive programming

Most of us write imperative applications, where statements are required in order to change the application state. The code is executed and a final state is arrived at. After the state's computation, the state does not change when the underlying factors do. Let's consider the following code as an example:

int value1 = 5;
int value2 = 10;
int sum = val1 + val2;
System.out.println(sum); // 15
value1 = 15;
System.out.println(sum); // 15

The sum is still 15, even though value1 has been changed.

On the other hand, reactive programming is about the propagation of change. It is also referred to as declarative programming, where we express our intent and application state as dynamically determined by changes to underlying factors. The preceding sum program example, under a reactive paradigm, would behave as follows:

int value1 = 5;
int value2 = 10;
int sum = val1 + val2;
System.out.println(sum); // 15
value1 = 15;
System.out.println(sum); // 25

Consequently, if a program reacts to changes in the underlying factors, it can be called reactive. Reactive programs can be built using imperative techniques, like callbacks. This may be fine for a program that has a single event. However, for applications where hundreds of events are happening, this could easily lead to callback hell; we could have numerous callbacks relying on one another, and it would be really difficult to figure out which ones were being executed. As a result, we require a new set of abstractions that enable us to seamlessly build asynchronous, event-driven interactions across a network boundary. There are libraries in different imperative languages, like Java, that provide us with these abstractions. These libraries are referred to as Reactive Extensions.