Before diving into the Reactive Manifesto, Reactive Streams Specification, or Java 9 Flow API, and Functional Reactive Programming (FRP), we will first understand the meaning of Reactive and Reactive programming in this section.
Introduction to Reactive
What is Reactive?
Reactive means reacting to changes in a timely manner or responding to changes in a timely manner.
Here, in the Reactive World, we can represent a change as an event. So we can also define Reactive as reacting to events in a timely manner. This change can occur on data or data elements.
Whenever a change occurs in our system, the system should react to those changes immediately in a timely manner. In the current world, users expect a response from an application (website, web application, mobile application, and so on) quickly and in a timely manner. If the system or application does not respond to the user (or customer) in a timely manner, the user will look for some other option and our application will lose its users.
In the Merriam Webster dictionary, Reactive means being readily responsive to a stimulus (check out https://www.merriam-webster.com/dictionary/Reactive).
In the Reactive World, a change is an event. In Reactive systems, we represent that event as a message. We will discuss why we need to represent an event as a message in detail in subsequent sections.
What is Reactive programming?
Unlike imperative programming (IP) or (Object-Oriented Programming) OOP, where we write our code in terms of the order of lines or statements, in Reactive programming (RP), we write the code or programs in terms of events.
In simpler words, RP means writing programs using events, or RP means writing programs that define how to react to events. As we discussed, events are changes in the state of the program or application. So we can also define RP as follows:
Reactive programming is a kind of programming paradigm to that propagates changes.
Let's discuss one of the important and frequently used RP examples (almost all books or tutorials use the same scenario). Consider the following example of a spreadsheet application:
Observe that the A3 cell has a formula =A1+A2, that is, A3 is the sum of the values of the cells A1 and A2.
Initially, A3 has a value of 0. When we change the value of cell A1 or A2, or both, the spreadsheet updates the value of A3:
We can observe that the cell A3 is updated with 3 automatically; this is Reactive programming.
What is a data stream or stream?
In Reactive programming, we write programs to work on a sequence of events. For instance, in a spreadsheet, we can observe the following events in a sequence:
- The user enters a value 1 into cell A1. When the user inputs data into cell A1, the value in cell A3 is updated to 1.
- The user enters a value 2 into cell A2. When the user inputs data to cell A2, A3 is updated to 3.
In the Reactive World, this sequence of events happening over time is known as a stream, events stream, or data stream. The following diagram shows how a sequence of events forms an events stream. It also shows how a Publisher sends events to an event stream and how a Subscriber receives events from that event stream:
A stream or data stream is a sequence of ongoing events ordered in time.
In RP, the Publisher sends events to a Stream, and the Subscriber consumes those events from the Stream.
To react to events, we should monitor them. In RP, the process of monitoring events is known as listening to events or subscribing to events.
We can also define RP using this data stream:
RP is a programming paradigm to do programming with asynchronous data streams.
Event stream = A sequence of events
RP versus Reactive systems versus Reactive architecture
A Reactive system is a set of components that communicate with each other reactively. By combining those individual components into one, we can form a modern distributed system. We can develop a Reactive system by following a set of architectural design principles.
Reactive system components work as a single system and they react to changes in a timely manner.
Reactive systems or Reactive applications have the following features:
- Responsiveness: They react to users in a timely manner
- Elasticity: They react to load
- Resilience: They react to failures
- Message-Driven: They react to events or messages
We will discuss these components of Reactive Streams in detail in the Reactive Manifesto section. Reactive Architecture is a technique or a process of designing Reactive systems.
We can develop Reactive systems using many techniques. However, RP or FRP are the best tools to build Reactive systems.
The core principle of a Reactive system is developing its components using a Message-Driven approach, whereas RP is all about writing programs using events, which means it follows an Event-Driven approach.
As we said, a Reactive system is a set of components. We use RP at the component level, which means that we develop each component using RP. We use a Reactive system at the system level.
Event-Driven versus Message-Driven
The core principle of RP is the Event-Driven approach, whereas the core principle of a Reactive system is the Message-Driven approach.
RP gives us the benefits at component level only because events are emitted and processed locally. They cannot work across the network in a distributed system.
Reactive systems give us the benefits at the system level, because messages are processed and communicated across the network in a distributed system.
We cannot get the full benefits just with RP; we should use the combination of RP and the Reactive system.
In a Reactive system with RP, generated events are represented as messages under-the-hood, and they are processed as messages.
Benefits of Reactive systems with RP
We will get more benefits when we use RP as a programming paradigm to develop the components of a Reactive system. The combination of RP and Reactive systems gives us the following benefits:
- Self-healing: As per the Reactive Streams specification, RP should support Resilience. This means we can write Reactive systems in a way that they have some technique to recover from failure and continue working to give responses to the clients. This is known as self-healing. A client will not know about this, and they will never see those failures.
- Highly available systems: As per the Reactive Streams specification, RP should support Elasticity (scale up/down and scale out/in). This means we can write Reactive systems in a way that they are always available. They support 100% up time.
- Highly Scalable to support heavy loads.
- Loose coupling.
- Utilizes system resources (both hardware and software) efficiently.
- Provides better responsiveness.
- Provides real-time behavior or data streaming.
- Easy to perform distributed data processing.
- Supports Location Transparency.
- Low latency.
- Better performance.
- Ease of maintainability.
- No need to use anonymous callbacks (so no more callback hell).
- Easy to address and handle failures.
- Easy to reason about failures.
We should also understand the things that are forcing us to develop and use Reactive systems:
- IoT (Internet of Things)
- Cloud environment or services
- Big data systems
- Real-time fast data streaming
- Mobile architectures
- Communication between heterogeneous systems
- Multicore hardware architecture
Here, Reactive systems means Reactive Web Applications, Reactive applications, and Reactive microservices. In my point of view, all have the same meaning.
So far, we have discussed Reactive World, that is, RP. Now, it's time to enter the Functional World, that is, functional programming.
