The Reactive Universe for Java Devs

It's undeniable that among the thousands of innovations that have emerged in the Dev (and Ops more recently) area, one of the most discussed topics is reactive programming. Whether the development of new FWs (Frameworks), such as the implementation for the Java language of ReactiveX (RxJava), the recent launch of Spring 5 with reactive programming, or even the launch of lambdas and streams in Java 8 (since 2014 ), it is clear that more and more reactive thinking is becoming present in the code and FWs that we use.

Since I am a Java Dev, I will try to comment here on what the main options Java developers today count on to create their applications. This can be a great option in various situations of the day-to-day programming, always remembering that it is important to evaluate the real need to use a complex or expensive resource to solve a problem (the famous ant-killing cannon). However, before leaving comments on the tooling that I see as the state of the art for reactive programming, I would like to briefly highlight the famous pillars of this paradigm (according to the Reactive Manifesto):

• Elastic — Reacts to demand/load — Applications can make use of multiple cores and multiple servers;

• Resilient — Reacts to faults —Applications react and recover from software, hardware, and connectivity failures;

• Message Driven — Event-driven — Instead of composing applications across multiple synchronous threads, systems are composed of asynchronous and non-blocking event handlers;

• Responsive — Reacts to users — Applications that provide rich, "real-time" interactions with users.

                                                                Figure 1. Characteristics of a reactive application

With regard to reactive programming models, they have emerged and improved to address problems known as blocking APIs, high latency, and synchronous processing among others. Following the purpose of this article, currently, the main searches and use in the projects that use Java are of the following tools:

RxJava

Despite being a well-known FW of the Java community, in my opinion,  RxJava still lacks in-depth use and study by the Java web developers. Today, the use is still very much present only in Android application development.

Although the RxJava does not use message orientation as the main functionality of FW, such as the Akka actor model (which I will comment on below), it offers many features in which message orientation becomes more evident. The best example of this is the subjects of the Rx. In short, subjects implement the Publish / Subscribe standard.

                                                       Figure 2. The Observable -> Subscribe pattern from RxJava

In RxJava, a subject represents an Observer and an Observable at the same time, allowing the multicasting of events from a single source to multiple Subscribers. Since the component responsible for the publication does not know who will be the consumers of the messages, this model guarantees low coupling between the components of the application.

Some Web FWs also use Rx as part of their implementations, like Vert.x, that implements RxJava's Observable and also implements a structure close to Reactive-Streams (No Vert.x 2.x). Finally, one of the highlights of this implementation is that RxJava also handles the back-pressure of streams very well, allowing the developer (through pre-defined methods in the API) to decide what to do with the stream that is 'clogged.' 

Akka

Akka is a Toolkit and Runtime for building concurrent, distributed, fault-tolerant, event-aware applications in the JVM. FW Akka can be used with Java and Scala. Actors are the unit of execution in Akka. The actor is an abstraction that facilitates the creation of simultaneous, parallel and distributed systems. The key principle behind an actor is that the application only interacts with him through messages and never speaks directly to him. This abstraction allows actor-based applications to scale transparently and maintain the low coupling level. Although this FW is not only characterized as reactive, it presents several characteristics of reactive solutions (such as resilience and elasticity), and even if originally written in Scala, it has a very easy integration for Java. As well as RxJava and Vert.x (with reactive-streams), Akka also implements in its streams the concept of Backpressure control, allowing a greater management and treatment of faults in the streams.

Akka has been integrating with Java for some time, but with Java 8 (with lambdas and streams) the integration has taken a more productive and more consistent form, as can be seen here (although it is 2014, it is still very valid the content of this article!)

                                                        Figure 3. Architecture of Messages x Actors in Akka

Reactor Project

This project consists of a series of functionalities that allow working with reactive streams in the JVM with FW Spring 5. This project is based on another pre-existing project called Reactor Cor that allowed Pivotal to improve and insert those functionalities launched in Spring 5. Much has taken advantage of the original design, allowing you to write high-performance, scalable, and fault-tolerant code in a simplified way. This is all in conjunction with the many features that Java developers already use from Spring.

The Reactor project is built from two main types, Mono <T> and Flux <T>. Both are considered data streams, up to 1 (Mono) or more (Flux) elements, and work by supporting the Publisher —> Subscriber pattern of streams. Spring 5 has already been released and the new reactive features are listed and discussed here.   

In the market today, I believe that these are the most practical and well-known options (with an active community and comprehensive documentation) to work with the concept of reactive programming in the Java language. If you have any suggestions or some use case to comment, I would love to know more! See you next time.