ReactiveX

Reactive Extensions, also known as ReactiveX, enable us to express the asynchronous events in an application as a set of observable sequences. Other applications can subscribe to these observables, in order to receive notifications of events that are occurring. A producer can then push these notification events to a consumer as they arrive. Alternatively, if a consumer is slow, it can pull notification events according to its own consumption rate. The end-to-end system of a producer and its consumers is known as a pipeline. It is important to note that pipelines are lazy by default and do not materialize until they are subscribed to by a consumer. This is very different from eager Java types, like Future, which represent active work. The ReactiveX API consists of the following components:

1. Observables: Observables represent the core concept of ReactiveX. They represent the sequences of emitted items, and they generate events that are propagated to the intended subscribers.

2. Observer: Any application can express its intent for events published by an observable by creating an observer and subscribing to the respective observable. The intent is expressed in terms of the OnNext, OnCompleted, and OnError methods. Each observable sends a stream of events, followed by a completion event, which executes these methods.
3. Operators: Operators enable us to transform, combine, and manipulate the sequences of items emitted by observables. The operators on an observable provide a new observable, and thus, they can be tied together. They do not work independently on the original observable; instead, they work on the observable generated by the previous operator to generate a new observable. The complete operator chain is lazy. It is not evaluated until an observer is subscribed to it. The complete chain is shown as follows:

ReactiveX provides the architecture design to build reactive applications. Individual libraries were built around it in different imperative languages to enable its use. These abstractions allow us to build asynchronous, non-blocking applications, and provide the additional benefits listed in the following sections.

Composite streams

In software design, composition refers to grouping different entities and treating each group as a single entity. Additionally, the single entity exhibits the same behavior as the type it refers to. ReactiveX streams are composite in nature. They make it possible to combine existing data streams, add transformations, and generate new data streams. Moreover, all of this can be done in a declarative manner, making the overall solution maintainable in the long run.

Flexible operators

The libraries offer a range of operators for all kinds of functions. Each of the operators accomplishes its tasks similarly to that of a workstation on an assembly line. It takes input from the previous workstation and provides input to the next workstation. These operators offer all kinds of data transformation, stream orchestration, and error handlers.

ReactiveX makes its easier to build event-based applications. However, the framework does not present the ways in which different event-driven applications should interact with each other. In a microservice architecture consisting of numerous event-driven services, the gains made are often offset by the workarounds required for inter-process communication.