In recent times reactive programming has been expanding more and more, it is already being addressed by several languages, but in Java is it something new for you? Then this series of articles is for you!
In this series of articles I will address issues such as reactive programming, Spring Webflux, Project Reactor and Netty.
In this first I will cover some general concepts before delving into each one of them, here we go:
The Problem:
We expect our applications to be scalable, we need to use resources more and more efficiently, latency time must be minimal, we need quick responses to our requests, we handle competing requests (each thread consumes a little memory), traditional APIs work in a synchronous and blocking way.
To solve this, we had the creation of Callbacks and Futures:
Callbacks are not easy to read and difficult to maintain, they are complex (they can form a hell callback), through which it is not possible to return any value.
Future: returns an instance of the future type and it is difficult to scale for multiple asynchronous operations, as an alternative, from Java 8 came the Completable Future that supports functional and easy programming the use of multiple asynchronous operations, however, as nothing is perfect , is not a good option for asynchronous calls with multiple items.
Alternative way to develop APIs
- Asynchronous and non-blocking
- Outside the on-demand thread model
- Decreases the number of threads created
And there comes reactive programming, ok, but what is different about it?
- asynchronous and non-blocking
- Data flow as an event / message driven flow
- Code maintains functional programming style.
- BackPressure in data streams
Let us turn more attention to the data flow part:
The data can come from databases, external files, integrated services, other applications, etc. For each item of this data source, we have an event or message that is triggered, after the execution of that event / message, we have an error message or that it was complete.
For a request to save data for example, we have an onNext(Product) event:
List <Product> products= productRepository.getAllProducts();
When we call data from a database for example, the call returns and for each item an onNext(Product) is launched and when we finish the listing we have an onComplete() event to inform that our request has ended.
What if our request has an error?
Instead of returning the onComplete() event, we will have the OnError() event and we will not have the expected content.
Reactive Stream Specification
is a set of specifications for the use of streams, created by companies like Pivotal and Netflix, among these specifications, we have:
- Publishers: The Publisher interface is a provider of an unlimited number of elements in a sequential manner and publishes them according to the demand it receives from its Subscribers (I will explain what is next). The same publisher can serve several Subscribers dynamically at different times. Publishers are our data sources.
public interface Publisher<T>{
public void subscribe (Subscriber<? super T> s);
}
- Subscriber: You only receive a call to OnSubscribe after you pass an instance of Subscriber to Publisher.subscribe (Subscriber). No notification will be received until Subscription.request (long) is called. After the call is initiated: One or more onNext(Object) calls are launched until the maximum number defined by Subscription.request(long) is reached. A single onError(Throwable) error call or complete onComplete() request. This demand can be signaled through Subscription.request(long) whenever the Subscriber instance can handle more.
public interface Subscriber<T>{
public void onSubscribe(Subscription s);
public void onNext (T t);
public void onError(Throwable t);
public void onComplete();
}
And the Subscription:
public interface Subscription{
public void request (long n);
public void cancel ();
}
- Processor: It represents a processing step, which is both a Subscriber and a Publisher that accepts both standards.
public interface Processor <T,R> extends Subscriber <T>,Publisher <R>{
}
being that :
T- type of element that is signaled to the Subscriber.
R- type of element that is signaled to Publisher.
This was the first part of the series of articles, in which we talked about some points and advantages of reactive programming, in the next I will address the reasons that led to the creation of Webflux and its differences from Spring MVC
Questions or feedbacks?
Below are some interesting references and content on this subject:
See you in the next articles!
Top comments (0)