Reactive APIs — A non imperative communication
We have been accustomed for many years to developing with an imperative and deterministic computing model. We can see that imperative programming is a programming paradigm that describes computing through actions, statements, or commands that change the state of a program.
If we look at the previous example all the commands will be executed as actions and in the written order.
When we externalize these kind of commands to Input/Output (I/O) operations, such as a database access, these executions happen synchronously, that is, the program will wait for the query result.
Alternative to Imperative and Blocking
In search of a computational model that is more efficient in computing resources usage and in the form of communication, I will highlight some of them in this section:
Async / Blocking
Thread management is not an efficient model for using computational resources. Not to mention that somehow you will have to block and wait for the response at some point.
Async / Nonblocking
This entire execution model happens around a continuous loop for functions that need to be executed, ie these functions go into standby mode when they execute an I/O operation and return to the loop when the I/O state was processed. It is worth mentioning that the event loop processes function one at a time.
This model became popular by the usage of Node.JS. So we can say that this model take I/O operations for granted to do asynchronous processing between all functions, but does not treat the information as an asynchronous data stream.
So, should ask ourselves: How can we achieve an asynchronous model that composes non-blocking data stream?
And the answer is: Reactive Programming!
Reactive — What it really means?
The reactive manifesto v2.0 was published in 2014 and basically established the following:
Response: The system responds in a timely manner if possible at all. Responsiveness is the cornerstone of usability and utility.
Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. The back-pressure strategy makes use of feedback among the parties involved in order to control the flow and elasticity of the data stream.
Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency.
Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems — any system that is not resilient will be unresponsive after a failure.
Reactive Programming Model
There are lot of bad explanations of what reactive programming is. To be crystal clear, reactive programming is programming with asynchronous data streams. It's possible to say that the reactive programming model has four principles:
- Non blocking
- Asynchronous
- Functional / Declarative
- Data Streams
A stream is a sequence of ongoing events ordered in time. It can emit three different things: a value (of some type), an error, or a “completed” signal.
Observer Design Pattern
Within this functional model of data streams composition, in the paradigm center is how the parts communicate with each other. Therefore the Observer Design Pattern is at the center of reactive programming.
The listening to the stream is called subscribing. The functions we are defining are observers. The stream is the subject (or “observable”) being observed. This is precisely the Observer Design Pattern.
The next example shows us how a click event data stream can be composed by the usage of declarative functional strategy:
Reactive API
So, what really is a Reactive API?
- Reactive APIs are: Web API Observer Pattern
- The request is the subscription -> subscribe();
- The server sends back the events as data stream -> onNext();
- The end of the response -> onComplete() or onError();
- This behavior is specified by the W3C as text event stream content type requisition named Server-Sent Events.
- https://www.w3.org/TR/2009/WD-eventsource-20090421/
Server-Sent Events specification defines an API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.
Project Reactor
Reactor is a fourth-generation Reactive library for building non-blocking applications on the JVM based on the Reactive Streams Specification. Reactive Streams Specification is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure.
- Reactor is a fully non-blocking foundation with efficient demand management. It directly interacts with Java 8 functional API, Completable Future, Stream and Duration.
- Reactor offers 2 reactive composable components: Flux [N] and Mono [0|1] extensively implementing Reactive Extensions.
- Suited for Microservices Architecture, Reactor offers backpressure-ready network engines for HTTP (including Websockets), TCP and UDP. Reactive Encoding/Decoding is fully supported;
Spring WebFlux
Spring Framework 5 embraces Reactive Streams as the contract for communicating backpressure across async components and libraries. Reactive Streams is a specification created through industry collaboration that has also been adopted in Java 9 as java.util.concurrent.Flow;
- The Spring Framework uses Reactor internally for its own reactive support;
- Spring Core 5 includes a new spring-webflux module that contains support for reactive HTTP and WebSocket clients as well as for reactive server web applications including REST, HTML browser, and WebSocket style interactions.
WebFlux can run on Servlet containers with support for the Servlet 3.1 Non-Blocking IO API as well as on other async runtimes such as Netty and Undertow.
REST-style JSON and XML serialization and deserialization is supported on top as a Flux<Object>, and so is HTML view rendering and Server-Sent Events.
Reference
To check a fully Reactive API using Spring WebFlux, please see my github project: https://github.com/rmzoni/webflux-test-api
Our goal in Product Technology is to create the best solution to our customers’ needs by offering the most complete and innovative portfolio of financial products from financing to investing. We’re here to build a fully automated and intelligent digital platform and we’re looking for people who’ll join us on this link.
