Deep dive into Reactive Programming Paradigm | Part-1

In this blog, we shall be looking at following concepts :-

  • Iterator Design Pattern.

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.

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.

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.

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.

Question:- How can we summarise the Observer design pattern in accordance with Reactive programming paradigm ?

  • FLUX is nothing, but the publisher.

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.

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)]

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.

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.

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.

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.

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 :-

--

--

Software Engineer for Big Data distributed systems

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store