Deep dive into Reactive Programming Paradigm | Part-1
In this blog, we shall be looking at following concepts :-
- Iterator Design Pattern.
- Observer Design Pattern.
- What is Flux.
- Difference between the Flux and Stream.
- Difference between the Flux and Mono.
- Terminal events with Flux & Mono.
Question:- Explain what is Iterator design Pattern ?
Question:- Demonstrate pictorially the working of Iterator design Pattern ?
Question:- Share some example of Iterator design Pattern ?
Question:- What is the main advantage of Iterator design Pattern ?
Question:- Explain what is Observer design Pattern ?
Question:- Demonstrate pictorially the working of Observer design Pattern ?
Question:- Share some example of Observer design Pattern ?
Question:- Showcase some example of Observer design Pattern from the Reactive Programming World ?
Step #1.) Here, we have declared a Flux, which is emitting 10 integer numbers, each with a delay of 1 second.
Note that, Flux is one of the type of special Streams. Here, Flux acts as the source of the events. It acts as the Publisher. We are using below dependencies, in order to construct this Flux.
We need to have following maven dependencies :-
Step #2.) Now, we are consuming/subscribing from the aforementioned Flux and thus performing the business action :-
- Whenever this stream (intNumbersFlux) emits something, I want to run a piece of code.
- At line no 12, whenever we receive some event, run the lambda function i.e. [e -> System.out.println(e)]
- At line no. 17, we are hanging around (we are waiting around) for the events to arrive. Note that, the numbers are being received, each with a delay of 1 second.
Note that, the code at line no. 12 can also be simplified as below :-
Question:- Can we attach/subscribe multiple subscribers to a single source ?
Answer → Yes. We can very well do the same. See below at line no. 15 and 16, we have attached multiple subscribers to the same stream i.e. Flux.
Question:- In reference to the above programming example, whether order of events is predictable with Reactive programming paradigm ?
Answer →
- The ordering is NOT predictable and it is not pre-deterministic.
- It’s not depending upon the subscription level, rather it’s changing depending upon the event level i.e. time when the events are published.
Question:- Showcase some another complex example of Observer design Pattern from the Reactive Programming World ?
Step #1.) Here, we have declared a Flux, which is emitting 6 different User objects, each with a delay of 1 second.
Note that, Flux acts here as the Publisher. We are using below dependencies, in order to construct this Flux :-
Step #2.) Here, is how the definition of User object looks like :-
Step #3.) Now, we are consuming/subscribing from the aforementioned Flux and thus performing the business action :-
- Again here, at line no. 17, we are hanging around (i.e. we are waiting around) for the events to arrive. Recall from step no. 1 that, the user-objects are being received, each with a delay of 1 second.
- At line no. 15, Whenever this stream (userFlux) emits something, we want to run a piece of code i.e. some lambda function i.e. [user -> System.out.println(user)]
Question:- How the Reactive programming is related to the Asynchronous programming ?
Answer →
- Reactive is NOT always Asynchronous. Reactive can be Synchronous as well. Async can be Non-Reactive too.
- We need something to be running, in order for Reactive Stream to be emitting.
Question:- How can we summarise the Observer design pattern in accordance with Reactive programming paradigm ?
- FLUX is nothing, but the publisher.
- Multiple subscribers can be attached to the Flux.
Question:- Whats the difference between the Flux and Stream ?
Answer → Flux is series of items over time, whereas the Stream is merely a collection of items all at once.
Question:- Can you demonstrate the conversion of Flux into a Stream ?
Step 1.) Recall that, we had our Flux with name intNumbersFlux. This Flux facilitates dynamic overtime arrival of elements.
Step 2.) Now, we shall be converting this Flux into a one time collection of events :-
Question:- Whats the difference between the Flux and Mono ?
Answer → Following is the difference between the Mono and Flux :-
- Mono is asynchronous sequence of ZERO or 1 item, that may or mayn’t come in the future.
- Flux is asynchronous sequence of ZERO to N items, that may or mayn’t come in the future. It could return 1 item as well, but Flux stays to be a Flux.
There is no similar concept with Streams. With Reactive programming, the concept of number of items is different. The difference here is, with the number of elements that either Mono or Flux intends to send.
Question:- Showcase some example of Observer design Pattern from the Reactive Programming World, using the Mono ?
Step #1.) Here, we have declared a Mono, which is emitting 1 integer number, with a delay of 1 second.
Note that, Mono is one of the type of special Stream. Here, Mono acts as the source of single event. It acts as the Publisher. We are using below dependencies, in order to construct this Mono.
We need to have following maven dependencies :-
Step #2.) Now, we are consuming/subscribing from the aforementioned Mono and thus performing the business action :-
- At line no. 12, Whenever this stream (intNumbersMono) emits something, I want to run a piece of code [number -> System.out.println(number)]
- At line no. 17, we are hanging around (we are waiting around) for the event to arrive. Note that, the number are being received, each with a delay of 1 second.
Question:- Can we block the value, which is being emitted from the Mono ?
Answer → Yes, we can block the value, which is being emitted from the Mono as shown below at line no. 15.
But note that, blocking on Mono/Flux is not a good thing. We are going to loose the benefit of the Reactive-Programming, because the whole reason we are doing Reactive Programming is to make sure we are not-blocking.
Question:- Now that, we understand what a Mono and Flux is, let’s revisit how does our API code look with Reactive Programming ?
Note here, following points :-
- We are now returning the Mono<User> type of object. It means the client/subscriber might get the 0 to 1 items.
- The Observer/subscriber is now waiting for the data to be returned by the Publisher/Sender.
Question:- What all items Mono and Flux, can send in the response ?
For a Flux, it can send first element as the complete event, indicating that the Flux returns ZERO items.
Question:- What are terminal events ?
Answer → Here we go :-
- The Complete Event is the terminal events i.e. the Flux/Mono would not be sending any event after the Complete event is being sent. There can only be ONE complete event.
- Similarly, the Failure Event is also a terminal event, which means once the failure is being sent by the Flux or Mono, it would not be sending any other event after that.
Note that, in case of Flux, once the item is emitted, there can be more items coming. In case of Mono, once an item is emitted, there can only be one more event which can be coming i.e. Complete-Event.
Question:- Can you demonstrate the terminal events with Mono ?
Answer → This is how, we shall be writing the subscribe definition for the Mono. There are 3 parts to it :-
- At line no. 13, the actual event being received is handled.
- At line no. 14, the error would be handled, in case it comes.
- At line no. 15, the completion event would be handled, as this is the terminal event.
Question:- Can you demonstrate the terminal events with Flux ?
Answer → This is how, we shall be writing the subscribe definition for the Flux. There are 3 parts to it :-
- At line no. 13, the actual event being received is handled.
- At line no. 14, the error would be handled, in case it comes.
- At line no. 15, the completion event would be handled, as this is the terminal event.
We can also see the text : “Complete” being printed in console, after all events are done sending by the Flux.
That’s all in this blog. If you liked reading it, please clap on this blog. We shall see you in next blog.
References :-