Reactive Programming: Blocking(Sync) vs Non-Blocking(Async) Request Processing

Blocking Request Processing:

Most of the time, when we expose any endpoint to external world, internally it follows below flow:

controller <-> service <-> dao <-> DB

The existing servlet frameworks, assign a separate thread to each request and that thread will be blocked for that user, until response is sent or process is erred out. Its a synchronized processing of each request.





Non - Blocking Request Processing:

This is the new style of programming, where the flow of processing would be same as below, however with each request we have event handlers and call back functions.

                                    controller <-> service <-> dao <-> DB

When any request comes, new generation of web containers ( like netty, undertow, Servlet 3.1+) will start assigning threads to each request, however as any request wait for any slow process to finish, that request will be moved to some kind of queue via handlers and that thread will be freed up for new requests, when slow process will finish for that request, callback will be initiated with received data. Here basically requests are asynchronous in nature and threads are not blocked.



image courtesy: https://howtodoinjava.com/spring-webflux/spring-webflux-tutorial/

Reactive Programming: What is it ?

Reactive means : Anything which responds based on some events.

If we go by the name 'Reactive Programming', it means a programming technique where things get executed based on some reactions or in programming terms events drive the execution.

Aren't we familiar with event based execution:

1. We have queues where in case of message arrival, some code get executed or
2. we have listeners which continuously listen to events, like arrival of some message on web sockets to process it.

So aren't we already writing reactive programs ? What is new here ?

The new is the level of complexities involved in the way we write Reactive Programs

1. These old way of reactive coding, we require a dedicated external system like queue for publishing and subscription. You require some sort of dedicated listener who can take care of every message arrival.

2. In case of plain java event based programming we have to block 1 thread which is continuously listening to the events and doing whatever needed.

In nutshell, old way of programming involves many components or wastage of precious resources to achieve reactive programming.

The new Reactive library will do away with this complexities and it provide in build APIs which do the job of reaction :) based on the events.

Whatever may be the paradigm, for reactive programming below three actors are must:

1. Observables : which will emit events called Publisher as well
2. Observers : which will consume events called Subscriber as well
3. Scheduler: which will schedule or control the flow of events

image courtesy: https://medium.com/@kevalpatel2106/what-is-reactive-programming-da37c1611382


Java 9 has a Reactive Stream API to support Reactive Programming. It majorly contains below 4 interfaces :

Publisher.java

public interface Publisher<T>

{

    public void subscribe(Subscriber<? super T> s);

}

Subscriber.java

public interface Subscriber<T>

{

    public void onSubscribe(Subscription s);

    public void onNext(T t);

    public void onError(Throwable t);

    public void onComplete();

}

Subscription.java

public interface Subscription<T>

{

    public void request(long n);

    public void cancel();

}

Processor.java

public interface Processor<T, R> extends Subscriber<T>, Publisher<R>

{

}

Spring Reactive: Spring WebFlux Vs Spring MVC

Details here:

Both work together to expand the range of available options. The two are designed for continuity and consistency with each other, they are available side by side, and feedback from each side benefits both sides. The following diagram shows how the two relate, what they have in common, and what each supports uniquely:

We suggest that you consider the following specific points:

• If you have a Spring MVC application that works fine, there is no need to change. Imperative programming is the easiest way to write, understand, and debug code. You have maximum choice of libraries, since, historically, most are blocking.
• If you are already shopping for a non-blocking web stack, Spring WebFlux offers the same execution model benefits as others in this space and also provides a choice of servers (Netty, Tomcat, Jetty, Undertow, and Servlet 3.1+ containers), a choice of programming models (annotated controllers and functional web endpoints), and a choice of reactive libraries (Reactor, RxJava, or other).
• If you are interested in a lightweight, functional web framework for use with Java 8 lambdas or Kotlin, you can use the Spring WebFlux functional web endpoints. That can also be a good choice for smaller applications or microservices with less complex requirements that can benefit from greater transparency and control.
• In a microservice architecture, you can have a mix of applications with either Spring MVC or Spring WebFlux controllers or with Spring WebFlux functional endpoints. Having support for the same annotation-based programming model in both frameworks makes it easier to re-use knowledge while also selecting the right tool for the right job.
• A simple way to evaluate an application is to check its dependencies. If you have blocking persistence APIs (JPA, JDBC) or networking APIs to use, Spring MVC is the best choice for common architectures at least. It is technically feasible with both Reactor and RxJava to perform blocking calls on a separate thread but you would not be making the most of a non-blocking web stack.
• If you have a Spring MVC application with calls to remote services, try the reactive WebClient. You can return reactive types (Reactor, RxJava, or other) directly from Spring MVC controller methods. The greater the latency per call or the interdependency among calls, the more dramatic the benefits. Spring MVC controllers can call other reactive components too.
• If you have a large team, keep in mind the steep learning curve in the shift to non-blocking, functional, and declarative programming. A practical way to start without a full switch is to use the reactive WebClient. Beyond that, start small and measure the benefits. We expect that, for a wide range of applications, the shift is unnecessary. If you are unsure what benefits to look for, start by learning about how non-blocking I/O works (for example, concurrency on single-threaded Node.js) and its effects.