Why and Who needs to read this? 

This article is for anyone who has been using Java, with MVC background, e.g. Spring boot, and wants to upgrade his coding to use Spring WebFlux. 

Kinds of programming

IMPERATIVE

Most of the programming that is practiced falls under IMPERATIVE Programming. A simple example can be of lets say writing Fibonacci series. You end up assigning values to variables, then running them through some loop e.g. a for loop, and then using some logic to change its value. If you are developing a backend in Java, most of the time you are likely using the loops, variables, assigning them some values and then changing it based on logic. 

In summary, IMPERATIVE programming is telling computer, HOW TO DO something 

A typical example is below in Javascript language 

DECLARATIVE

However, there is another kind of coding that is also popular, and it is known as DECLARATIVE programming. Here we just write what the result should look like, rather than telling how to obtain the result. 

If you are a front-end engineer, you are probably using HTML & CSS. For example

Here, you are just using declarative programming. You are just telling the browser to display an image without really bothering about how it is to be done.

Again, what about SQL programmers? 

Let’s say you have a table like below

And you run a query 

This is an example again of declarative programming, where you are telling what is to be done, rather than bothering about how it is to be done. 

And this is declarative programming v/s imperative programming i.e. “WHAT TO DO” v/s “HOW TO DO”

FUNCTIONAL

This can be thought of as a restricted way of DECLARATIVE programming, in which you are getting desired results by chaining two or more functions together. 

This means that functions/methods can now be assigned to variables, added to objects and array. You can pass them as argument to function (chaining), they can be returned to function calls. 

Another important thing is that now Data is immutable, so to change it, whether it’s a variable or object, you make copies of it.

And combining the above two concepts, you come up with Functional Programming, that is Functions change the data by returning new copies of data. In fact, for Functional programming to work, the functions must follow the rule of PURE function. A PURE function do not have side effects like network or database calls, the return value solely depends on the arguments it has.

Let’s try to understand Functional programming by an example. 

Refer to the 3 functions below. 

• The first one prints Fibonnaci series till the “max” number is reached.
• The second one just checks if the given number is even or not
• The third function sums the two numbers given

Now, let’s try to write a functional program to find the sum of all the EVEN numbers in the fibonacci series till max value of 1000.

Explanation of above code: We begin by returning our fibonacci numbers, which we pass our maximum value of 1,000 to, that have been stored in an array. We then filter that array and pass our filter method with our isEven function. This updates the array to only return the fibonacci sequence numbers that are even. To perform our final task of summing those numbers together we pass our sum function to our reduce method. 

The above is the power of functional programming - 

• Execution of series of mathematical functions
• Function does some specific computation but do not modify data

REACTIVE

Let’s say we are writing a simple Task Allocator. So there are two simple UI - the first UI is where the Manager allocates the tasks to his team, while the second UI is what different team members have. The Tasks are all stored in DB.

In a normal way of coding, let’s call it proactive, the team member”s UI will get updated whenever the DB has updated entry against his name.

Another way, that is reactive, is when

• DB just provides a ‘listener’ - that is it does not know about UI, it does not push out any messages to UI, all it does is provide listener and anyone can register to it.
• The team members UI registers to listener and updates itself based on logic.

So that main difference here is that 

• PROACTIVE - 
  1. UI is controlled by DB, the DB pushes changes to UI and it is updated. 
  2. DB is responsible for pushing messages to UI
• REACTIVE
  1. UI is controlled by itself. It listens to the changes and has logic to update itself
  2. The DB doesn’t do anything except for providing a listener where the changes are published. It does not know about UI or any other player. 

Understanding OBSERVABLE

While writing REACTIVE code, there are additional challenges. 

• Let’s assume that Admin, through his UI adds ONE task for Team Member A in DB
  • The listener function will return the information about the change.
  • The Team Member A UI is listening and will update itself based on this information.
• Let’s assume that Admin, now adds multiple tasks for Team Member A in DB
  • The listener function will now return a LIST of the information changes
  • The Team member A UI will update itself
• However, it is not necessary that Admin changes to DB will occur in the same precise way in which he has ordered the tasks for Team Member A. There can be multiple reasons for it, for example may be Admin is using multiple threads to write changes to update DB. It is also possible that some tasks are not written to DB.
  • The above is most often the case in real life and hence we have the concept of OBSERVABLE

The OBSERVABLE is a 

• collection of items over time 
• it can complete successfully 
• or terminate

Webclient

Backpressure