Most of the conversations about reactive programming didn’t accurately convey its meaning. In fact, reactive programming is aimed at effective resource use, asynchrony and non-blocking.
Reactive streams are asynchronous thread processing, so a publisher and a subscriber shall be required. All reactive systems are built on this principle. The publisher publishes the data stream, and the subscriber uses the data. Sometimes we have to convert data between the publisher and the subscriber. According to the chart, the Publisher publishes the data stream, and the subscriber uses the data. In the Subscription, by request, cancellation and upon request, we will receive onNext (onError / onComplete).
It depends on how successfully the action was completed. It’s important that a set is returned on onNext, then onNext will be called several times.
According to the manifest, reactive programming should contain the following architecture:
As described in the reactive manifesto there are different scenarios: Responsive (responsiveness of the system), Resilient (stress resistance, in the event of a system failure we do not cause a failure at all), Elastic (dynamically reacts to load) and Message-Driven. The system should essentially provide an answer in a reasonable amount of time.
Frameworks (Framework can be used instead of applying any third-party libraries to write the code.):
Libraries
Let’s start with Project Reactor, the first to implement this reactor paradigm in Spring. It has created a set of reactive primitives that simplify the work and work over Publisher-Subscriber and provide Fluent API. It consists of:
Micro Reactive Toolkit for all:
Spring WebFlux
Databases should be non-blocking database IO with WebFlux. A typical back-end looks like this:
If you briefly summarize the database should be an asynchronous driver from database developers.
this.mongoTemplate.inTransaction() .execute(s->Flux.just("First name", "Last name") .flatMap( name->s.insert( Call.bulder .title(name) .content("name - " + name) .build() ) ) ) .subscribe( v -> log.info("One name"), e->log.error("Error"), ()->log.info("data") );
In the example, a transaction enables us to get a connection. We create Flux from a constant and insert it into the database. When the transaction has been done, we perform a subscription. As the first signature, we use lambda.
Server implementation should be non-blocking HTTP with WebFlux support.
Servers:
Client:
The concept of Vert.x is to be reactive, unlike Spring. Spring rewrites its codebase with WebFlux, which has serious doubts about the realizability of this rewriting, against Vert.x.
The principle is such as EventLoop, which is spinning on Thread: some Events can wait, then something next is taken. If you have a lot of Thread, then Vert.x will be able to cluster them even outside of one machine, and to abstract you from how much Thread you have.
public class ServerVerticle extends AbstractVerticle { @Override public void start(Future<Void> startFuture) throws Exception { vertx.createHttpServer().requestHandler(req -> { req.response() .putHeader("content-type", "text/plain") .end("Start Vert.x"); }).listen(8080); } }
To write reactive code, Vert.x uses a Verticle that listens to requests. A request sends an event, and everything is updated asynchronously-reactively and processed. If there is a delay, then it goes to the background and the next request is processed.
I found Benchmarks showed that in fact there is no difference between Spring and Vert.x in the number of requests. The quality of resources consumed like Vert.x is very profitable. If a large load is not the number of requests, and the load on the server, this approach can save resources.
Actually, reactive programming sounds beautiful, the concept is also good, but it has some extra complexity:
First of all, you should estimate the system to choose a technology stack. As in the case of reactive programming, the presence of one event blocking, reactivity will lose all sense. Spring Reactor should be used for the project built on the Spring ecosystem, and Vert.x is preferable for the project written from scratch or Vert.x ecosystem. So, Spring Reactor and Vert.x are fast-growing technologies, and soon we will see what technology has been more viable.