Reactive Programming

Why Reactive Programming:

Before talking about reactive programming, let’s summarize what we were before 10–15 years ago. In the software world, we were using monolith architecture. Most of the servers run on app servers. We hadn’t figured out the mechanism of the distribution systems.

Today our architecture is microservice-based. Nowadays our server runs on the cloud. And we had figured out the distributed system which is much more effective.

Expectations from the software

Today we are expecting from the software that it should be scaled up based on the load. So that it can use its resources efficiently. A server should be much much faster.

Limitations of the traditional software design

It limits the concurrent user at a time. It is blocking and synchronizing. Traditional APIs did not support the back pressure.

Better design API

A server can support multiple concurrent users at a time. It shouldn’t be blocking or synchronizing. It should be compatible with back pressure. It should use fewer threads.

Reactive Streams

Dictionary says: A stream is a steady flow of something

For computing, a stream consists of a producer of data and the subscriber of data. And the data starts flowing from producer to subscriber when the subscriber subscribes to the producer. In between, there can be multiple stages modifying the data as described in the below diagram

This was about the general streams. Now, what makes a stream reactive?

1. Asynchronicity: The producer produces the data asynchronously and the data flows asynchronously through the processing stages.
2. Non-blocking backpressure: It is a mechanism where the consumer can request the producer to slow down, whenever the consumer is slow in processing data

You can visualize reactive streams as the assembly line in a manufacturing company. Whenever raw material is available at the source(producer) in the assembly line. At specific points, the item is transformed/processed/added to a new feature in the assembly line. At the end(subscriber) of the assembly line, we get the finalized product.

Assembly line

These were all the general concepts which stayed the same no matter which reactive framework you are using.

The core of reactive programming is signal. We will receive a signal whether it should be a data signal or an error signal.

There are the four main/core things/interfaces in the reactor.

• Publisher(producer)
• Subscriber(subscriber)
• Processor(transformer)
• Subscription(life cycle)

Publishers

The reactor provides two main publishers.

• Flux (multiple signals)
• Mono (single signal)

As the name suggests it is a producer/publisher which produces the data/signal. It will not produce the data until nobody subscribes to it. To create a Mono or Flux you can use the static method just()

Mono.just(1)

Flux.just(1,2,3,4,5,6,7,8)

Subscriber

The subscriber is the other end of the reactive stream which is the receiver of the signals/data. It receives the final output of the reactive stream.

Processor

The processor is the main part of the stream. In the processor, we modify data/signals. There are some methods which are used to process the data.

1. Map
2. FlatMap
3. Filter
4. onErrorMap
5. onErrorResume

There are some other methods which are provided in the reactive programming

Subscription

A Subscription represents a one-to-one lifecycle of a Subscriber subscribing to a publisher. In subscription, we can request the publisher to send data or request to stop sending data.