Intro to API designing with Reactive Programming Paradigm

In case you are landing here directly, it’s advisable for you to read this article and this article first, but it’s not that die-hard requirement as you still would be able to follow this blog.

Question:- What is Reactive programming ?

Question:- What is the meaning of declarative way of Programming ?

Answer → This is what I want to happen and then something is going to make it happen.

Question:- What’s the wikipedia definition of Reactive Programming ?

Question:- What’s the relationship between Async and Reactive Programming ?

Answer → Reactive Programming doesn’t necessarily implies Async. We can have Reactive Programming, which is Synchronous too. These 2 are separate concepts.

Question:- What are the use-cases of Reactive Programming ?

Answer → Classic use-case for Reactive Programming is Events. Although, we do have Swing, Java-Fx, etc. but still, of-course Java is not the first choice, while working with the Front-Ends. For example →

Basically, some Trigger leads us to do some thing here. We are reacting to some trigger.

Question:- How does traditional Server side Web-development works ?

Question:- What are the characteristics of current day modern applications ?

Question:- With modern applications, how do we do scaling ?

Question:- Let’s see the below code and identify, what are the problems with this code-piece ?

Here, there are two calls that we are making :-

In an ideal scenario, the statement no. 2 doesn’t have to really wait for the statement no. 1 to complete, but it’s just waiting un-necessarily. So, the problem in above code is that, the two statements (1 and 2) are un-necessarily sequential and the threads are Idling (i.e. Thread is waiting un-necessarily).

Question:- What’s the biggest cost associated with the above programming fallacies and who has to ay that cost ?

Answer → The cost of this problem is that, we are penalising on the performance to the User (i.e. the one person, who made this request).

Question:- What’s the another issue with the above programming fallacy ?

Answer → Let’s understand the working of a typical web-server :-

Now, the problem here is that :-

In nutshell, we are actually letting the thread-A to wait un-necessarily on statement no. 1 (getUser() function) to complete. If that thread would not have waited on the server, then this thread would not had been idle on the server and this thread could have handled another request.

Question:- What do we usually do, to solve this problem, as on current date ?

Answer → We would be doing Scaling i.e. we shall be :-

Question:- What’s the another big problem associated with this programming practice ?

Question:- What’s our programming behaviour with Imperative Coding Style so far with Spring Boot Framework ?

Question:- Does Concurrency APIs also provides an alternative to the Sequential Programming Style ?

Answer → CompletableFuture is an API, that’s available since very long time since JDK8. It implements the Future interface and works with CompletionStage to coordinate async operations.

Whenever userService.getUser(userId) operation completes, this object userAsync is going to inform us, about the same.

Question:- Can you showcase, how our original code would look like with Futures and whether this is best solution ? If not, are there any problems with the Futures ?

Answer →

This code is little optimised, but still there is a room for improvement here, because still number of threads piles-up at the server. And This is the problem.

The solution to this problem is defined as follows :-

Question:- Can you demonstrate, how our API-code would be different with Reactive Programming paradigm ?

Answer → Note here that :-

Question:- What are advantages with Reactive Programming paradigm ?

Question:- Explain Reactive Programming paradigm ?

Question:- What are the precautions, that we should take care while coding with Reactive-Programming ?

Answer → We should not be choosing this paradigm, if the application is not going to have enough load/foot-fall.

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