Vert.x is a toolkit for building an asynchronous and reactive application on the JVM. Initially inspired and influenced by node.js and truly those that know node.js will probably find many common elements, but since its creation Vert.x has taken a course of its own toward providing easy-to-use, resource-efficient, asynchronous, and reactive development tools. Important to know is that Vert.x is polyglot since it supports most of the popular JVM languages: Java, Scala, Groovy, Kotlin, and more. Some of the most basic concepts in Vert.x that requires some explanation at the beginning are Event loop, Verticle, Event bus. Take a look at more details on this link: https://simple-task.com/news/basics-of-vert-x/

1. Intro to Vert.x

2. What is Vert.x

Let’s be honest, it’s node.js for JVM.

It’s polygot since it supports a few JVM languages: Kotlin, Scala,
Groovy,Ruby ,Java (depending on version maybe a few more).

3. Basic concepts in Vert.x

Event loop

Verticle

Event bus

And Vertx instance

Most of Vert.x API is event driven. So when you what to know
something happened Vert.x will send you event.

“Don’t call us, we’ll call your handler”

4. Vertx

What is Vertx instance:

As documentation says: “In the beginning there was Vertx”

Vertx instance is more or less control center of Vert.x based
app.

Most often it’s one per application.

Used to create various servers, clients, timers and much
more.

5. Event loop

1 event loop -> reactor pattern

More event loops -> multi reactor pattern

Vert.x uses implementation of Multi-Reactor Pattern

One event loop is always running on the same thread.
BIG RULE: Never block event loop.

6. Verticle

What is Verticle:

It’s combination of Vertx instance and dedicated Context

OK, but what is Context?

Well that is a tough one. But I guess simplest is that context allows us to call the user defined
callback on the verticle event loop thread. Remember events can come from other event loops.

7. Event bus

Means for sending and receiving messages in an asynchronous fashion.

Event bus allows for decoupling between verticles.

But even more than that, since Vert.x is polyglot verticles written in different languages can communicate using event bus.

Three basic patterns of communication:
1) Point to point
2) Request-reply
3) Publish/subscribe

But is it a message broker? Well no

It’s intended more for verticle-to-verticle communication inside an application, and not as message bus for application-to-
application communication

8. Different ways to write async code

Vert.x provides different coding styles to create non
blocking code:

Callback

Future/Promises

Reactive extensions (RxJava)

Kotlin coroutines

9. Classical callbacks

10. Futures and promises

Promise is used to write an eventual value, and a future is used to read it when it is available.

Promise is created by a piece of code that wants to perform async operation. Once async operation is done we complete the
promise. And via the future we get from the promise object we react to completed async operation

But even more, we can also take advantage of some more interesting capability of Vertx Future’s class:
 Future<T> recover(Function<Throwable,Future<T>> mapper) - recover in case of error
 Future<U> flatMap(Function<T,Future<U>> mapper) - composes with another future

11. Futures and Completable Stage

Vertx futures can work together with java.util.concurent.CompletionStage

Let’s refresh, CompletionStage is step in async operation.One of the most important thing with CompletionStage is
that we can chain them in various ways.

While Vertx Future knows how to play with CompletionStage, they are not a subtype of CompletionStage interface.

To get CompletionStage object from the Vertx future we have to call vertx Future method:
 CompletionStage<T> toCompletionStage()

12. Reactive extensions (RxJava)

Some basic concepts from reactive extensions:
-
Observing event streams (Observable)
-
Operator composition to transform (Operators)
-
Subscribe to stream (Observer)

RxJava operators produce observables that are observers of the Observable they are called on
Type Description
Observable<T> A stream of events of type T
Flowable<T> A stream of event of type T.
Supports back-pressure
Single<T> Source that emits exactly one
event
Maybe<T> Source may emit one event,
or none

13. RxJava+Vert.x

Since working with RxJava results in entire different API for Vert.x to use this API new
dependency needs to be added.

Also most of the classes now used are in package io.vertx.reactivex.*

For example io.vertx.reactivex.core.AbstractVerticle as opposed to the one we used until
now io.vertx.core.AbstractVerticle

Most of the rxJava metods are prefixed with rx****()

Another thing to keep an eye on, rxJava often creates thread to handle some operation, and vertx
handles it’s own threading model in some situations it’s good to be aware of this fact.

14. ReadStream and WriteStream

In case of reading files, Http requests/responses, data from sockets we need something better than
some standard java InputStream or OutputStream since we are in non blocking environment.

To help with that Vert.x provides ReadStream and WriteStream across several type of resources

Core of both these abstractions is:
 Methods for reading/writing data
 Methods for back-pressure management

15. ReadStream and WriteStream

Example read file:
 How do we do it “classically”?
 What is the difference between vert.x approach and classical
 One pulls data, other pushes data
 Great,right?

16. ReadStream and WriteStream

So we need back-pressure

Different back-pressure strategies:
 Control
 Buffer
 Drop

Lucky for us ReadStream and WriteStream implement control strategy

Idea is following, for example when reading file to http response:
 While vert.x is pushing read buffers we are writing it to response stream
 Check if write buffer is full
 If it is full:

Pause the read stream

Install drain handler that resumes the file read stream when called

17. Is this reactive?
●
Reactive programming
●
Reactive systems