Everyone's talking about Reactive!

It is hard to escape the discussion around Reactive systems! It’s a buzzword you’ll particularly hear at the moment when people talk about graphical user interfaces (GUIs) and web application frameworks such as React.js.

But what does Reactive mean for developers not working on GUI / web front end applications? In this blog we will look at the concepts behind reactive systems and the ReactiveX project. In a number of future blogs, we will explore how different languages have implemented the reactive model including RxJava, RxKotlin and RxPy.

What is a Reactive Application?

A Reactive Application is one that must react to data. Typically, this occurs when new data is generated or in response to changes in the state of existing data. The Reactive manifesto presents the key characteristics of Reactive Systems as:

• Responsive. This means that such a system must respond in a timely manner. This is naturally somewhat subjective and may differ from one application / domain to another; a one-second response may or may not be timely depending on the scenario.
• Resilient. Such systems stay responsive in the face of failure. The systems must therefore be designed to handle failure gracefully and continue to work appropriately if something goes wrong.
• Elastic. As the workload grows the system should continue to be responsive at scale.
• Message-Driven. Information is exchanged between elements of a reactive system using messages. This ensures loose coupling, isolation and location transparency between these components.

As an example, consider an application that lists a set of Equity Stock Trade values based on the latest market stock price data. This application might present the current value of each trade within a table. When new market stock price data is published, then the application must update the value of the trade within the table. Such an application could be described as being reactive.

...So Reactive Programming is a programming style that follows the ideas of reactive systems.

The ReactiveX Project 

ReactiveX is the best-known implementation of the Reactive Programming paradigm. It is an extension of the Observer-Observable design pattern and supports sequences of data and / or events and adds operators that allow developers to compose sequences together declaratively while abstracting away concerns associated with low-level threads, synchronisation and concurrent data structures etc.

The ReactiveX project has implementations for many languages including RxPy, RxJava and RxKotlin.

The Observer Pattern

The Observer Pattern is one of the so-called Gang of Four patterns (originally described in ‘Design Patterns: Elements of Reusable Object-Oriented Software’ by E. Gamma, R. Helm, R Johnson and J. Vlissides, Addison Wesley, 31 Oct. 1994). It provides a way of ensuring that a set of objects will be notified whenever the state of another object changes.

There are two key roles within the Observer Pattern, these are the Observable and the Observer roles.

• Observable. This is the object that is responsible for notifying other objects that a change in its state has occurred
• Observer. An Observer is an object that will be notified of the change in state of the Observable and can take appropriate action (such as triggering a change in their own state or performing some action).

These concepts are illustrated in the following diagram:

In the above figure, the Observable object publishes data to a Data Stream. The data in the Data Stream is then sent to each of the Observers registered with the Observable. In this way data is broadcast to all Observers of an Observable. The process of registering with an Observable is referred to as subscribing.

If the Observable publishes data at a faster rate than can be processed by the Observer, then the data is queued via the Data Stream. This allows the Observer to process the data received one at a time at its own pace; without any concern for data loss.

Advantages and Disadvantages of Reactive Programming

As with anything there are both advantages and disadvantages associated with the Reactive approach.

The advantages of Reactive programming include:

• Avoidance of multiple callback methods. Many web-based GUI libraries have used callbacks as a way to help structure user and server interactions. The problems associated with the use of callbacks are sometimes referred to as callback hell. This can occur when there are multiple callbacks, all defined to run in response to some data being generated or some operation completing. It can be hard to understand, maintain and debug such systems.
• Simpler asynchronous, multi-threaded execution. The approach adopted by RxJava and RxKotlin makes it very easy to execute operations / behaviour within a multi-threaded environment with independent asynchronous functions.
• Availability of predefined operators. The RxJava and RxKotlin libraries come prebuilt with numerous operators that make processing the data produced by an Observable much easier.
• Data composition. It is straightforward to compose new data streams from data supplied by two or more other Observables for asynchronous processing.

The disadvantages of Reactive programming include:

• Easy to over-complicate things. When developers chain too many operators together or attempt to create too complex a set of functions with the operators, it can become hard to understand what is going on.
• Misunderstanding of basic concepts. Many developers think that Reactive Programming is inherently multi-threaded; this is not necessarily the case; many operators / functions work sequentially, whether the overall effect runs in multiple threads or not depends on the schedulers used or the operators being applied.
• Memory overheads. Some applications can become prohibitively memory intensive. This is because data streams need to store the published data so that Observers can process that data when they are ready.

Differences between Event Driven Programming and Reactive Programming

In Event Driven Programming an event is generated in response to something happening. The event then represents this with any associated data. For example, if the user clicks the mouse then an associated MouseClickEvent might be generated. This object will usually hold information about the x and y coordinates of the mouse along with which button was clicked. It is then possible to associate some behaviour (such as a function or a method) with this event so that if the event occurs, then the associated operation is invoked, and the event object is provided as a parameter.

This is certainly the approach used in many windowing libraries. The idea is illustrated in the following diagram:

In the above diagram, when the user clicks on a button a MoveEvent is generated, this causes the on_move() method to be called and the event is passed into the method.

In the Reactive Programming approach, an Observer is associated with an Observable. Any data generated by the Observable will be received and handled by the Observer. This is true whatever that data is, as the Observer is a handler of data generated by the Observable rather than a handler of a specific type of data (as with the Event driven approach).

Both approaches could be used in many situations.

For example, we could have a scenario in which some data is to be processed whenever a stock price changes.

Summary

Reactive Programming libraries such as RxJava and RxPy allow responsive, scalable message driven systems to be created. These libraries typically make the creation of such applications straightforward and reliable.

---

Would you like to know more?

If you found this article interesting and you're ready to take the next step, take a look at some of our courses which feature modules on Reactive Programming concepts:

• React.js training course
• Reactive Java Programming training course
• Modern JavaScript training course
• Advanced Kotlin & Ktor training course