In the earlier section of this chapter, we covered how application requirements have drastically changed over the last decade. To cater to this, there is a concept of application development named reactive applications.
It is important to understand the difference between reactive programming and reactive applications. Employing reactive programming doesn't produce reactive applications, but concepts of reactive programming can definitely aid in building reactive applications.
Knowing the Reactive Manifesto will help you understand reactive applications/systems because the manifesto clearly dictates each and every aspect of reactive applications.
A manifesto is apublicdeclarationofintentions,opinions,objectives,ormotives,asoneissuedbyagovernment,sovereign,ororganization (http://www.dictionary.com/browse/manifesto).
The Reactive Manifesto clearly articulates the views of the issuer, following which an application can be developed to be reactive.
According to the Reactive Manifesto (https://www.reactivemanifesto.org/), a reactive system should be responsive, resilient, elastic, and message-driven.
Let's get into each of these terms in a bit more detail. Most of the text in this section is from the online Reactive Manifesto and then slightly modified to convey the concepts in more easily digestible terms for the readers.
In case of problems, responsive systems can quickly detect them and effectively deal with them. These systems also give consistent response times and also establish upper bounds, guaranteeing a minimum Quality of Service (QoS). Because of such characteristics, these systems build end user confidence, simplify error handling, and encourage more interaction from end users.
In the case of failure, resilient systems stay responsive and interactable. Resilience in an application can be achieved by:
- Replication: Running the same component in more than one place, so that if one fails, another could handle it and the application can function in a normal fashion.
- Containment/isolation: Issues of a particular component are contained and isolated within that component and don't interfere with other components or other similar components spun up as part of replication.
- Delegation: In the case of an issue in a component, without much deliberation, the control is transferred to another similar component that is running in a completely different context.
Elastic systems can easily autoscale (increase or decrease resources) as the input rate increases or decreases. Such systems don't have any contention points and can replicate components at will, distributing the increase in load. The way these systems are designed makes sure that when scaling is required, it can be done in a very cost-effective manner by adding on more commodity hardware and software platforms as opposed to expensive hardware and licensed software platforms.
In reactive applications, one of the main aspects is the usage of asynchronous messages to pass data from one component to another. This brings loose coupling between components and aids in achieving location transparency (as long as the component is reachable/discoverable, it can reside in a single node or a cluster of nodes anywhere). Create a message, publish, and forget. Registered subscribers receive the message, process it, and broadcast the message for the other subscribes to do their jobs. This is one of the core aspects of reactive programming and it is one of the fundamental aspects needed for a reactive system. This fire-and-forget concept brings in a non-blocking way of communication, resulting in highly scalable applications.
The following diagram (Figure 1) clearly shows the Reactive Manifesto in a pictorial fashion. It also clearly shows the relationship between the main concepts on the Reactive Manifesto:
Figure 1: Reactive Manifesto
Since reactive applications are responsive, resilient, elastic, and message-driven, these applications are inherently highly flexible, highly scalable, loosely coupled, and fault-tolerant.
Mateusz Gajewski, in one of his presentations shared on www.slideshare.net, sums up the Reactive Manifesto in a very nice way:
Figure 2: Reactive Manifesto as conceived by Mateusz Gajewski