Skip to main content

My first day playing around with Vert.x

I have been reading quite a lot about Vert.x recently and finally the day before yesterday I sat down and spent some time exploring it by writing some code. Today I would like to present the outcome.

A little bit of history

Like all Reactive frameworks/tool-kits/libraries, Vert.x is inspired by Node.js.
Back when it was released, Node.js shocked many Java developers who looked down on Javascript, on top of owning the Web client side, JS wanted to conquer also the server side!
And thanks to its non-blocking nature, Node.js performed better than typical Java application servers such as Tomcat or Glassfish.
Then the Java world reacted (pun intended) and today Vert.x is one of the most matured reactive technologies for the JVM.

First Vert.x application 

When trying to build my first super-simple reactive (not really) application using Vert.x, I started following this tutorial from the lead developers of Vert.x.
That's great stuff, but I found it a little overwhelming as the first hands-on experience. I understand that the authors are eager to highlight most of the nice features of the technology but I decided to write my own example focusing just in the very basics.

The example application uses Java 8 and Maven and no custom Vert.x configuration (just the default). The main class creates one main verticle and then that verticle creates two more verticles: 
PublisherVerticle and ConsumerVerticle. 
The PublisherVerticle simply publishes (broadcasts) five messages using JSON as serialization and the ConsumerVerticle receives the messages and just logs their contents.
The messages are just POJOs.

At this point, you may wonder what a verticle is. Vert.x uses its own terminology, I recommend this post in order to get familiar with it. In simple words, a verticle is a Java class whose life-cycle is managed by a Vert.x instance and it can deploy and start other verticles,  it can also communicate with other verticles using the Event Bus.

This example is useful for people who are new to vert.x since it showcases the following:
- how to start vert.x
- how to deploy and start verticles
- how to serialize/marshal a POJO to be encapsulated inside a vert.x message using JSON
- how to publish a message to the vert.x event bus
- how to receive a message from the vert.x event bus
- how to construct a POJO from the received message
- how to stop vert.x
- the asynchronous behaviour of vert.x

And here you have the code.
Looking at the pom.xml you'll see that just adding the vertx-core dependency is enough, as usually, Maven will download the required transient dependencies for us:


As you can see, Vert.x uses Netty for the network communication (I like that it does not force you to use HTTP only) and Jackson for JSON serialization.

To run the example application you just need to execute its main class class, and looking at the output helps to understand the "everything asynchronous by default" philosophy of Vert.x. 
Even the call to start Vert.x is asynchronous, that is why the main method is the first one to finish:


We can also confirm that Vert.x manages the pool of threads for us so we do not need to worry about it.

Since this is a simplistic example, all verticles run on the same JVM/process, but one of the features of Vert.x is its convenience to implement microservices, thus, I could easily refactor the application in order to place each verticle in a different (Maven) module (and run it on its own runtime environment or in different machines) but that's subject for a future post.

Vert.x is a broad topic and I would like to highlight what this post does not cover and I may explore in the future:
- using a different serialization other than JSON (Google protobuffers for example)
- communication with external services (using HTTP or simply TCP or Websockets) either directly or through the Event Bus.
- using Vert.x as the back-end for a Web app (front end could be Angular or React)
- using Vert.x as the back-end for a native mobile app (probably Android since I already have some experience)
- Vert.x cache capabilities (Shared Map) 
- using different instances of Vert.x in the same application

Thanks for reading!

Labels:

Comments

Post a Comment

Popular posts from this blog

Kafka + WebSockets + Angular: event-driven microservices all the way to the frontend

In the the initial post of the  Event-driven microservices with Kafka series (see here  or  here ), I talked about the advantages of using event-driven communication and Kafka to implement stateful microservices instead of the standard stateless RESTful ones. I also presented the architecture and the source code of a related proof of concept application. In this post, I would like to show how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. Hence, in the first post of this series, we got rid of HTTP as the communication protocol among microservices in the backend, and now we are also replacing it (with WebSockets) as the communication protocol between the frontend and the backend. Ok, but why would you do that? Because it provides a better experience to the end user!. Using WebSockets you can build legit  real-time user interfaces, the updates are pushed immediately from the server to the client
2 comments
Read more

Cómo pedir cita previa en la DGT y desesperarse en el intento

El uso de la tecnología para la agilización de la administración española es simplemente bochornoso (y me quedo corto). Además todo el mundo lo sabe, sin ir más lejos, la última gran chapuza  informática en el Ministerio de Justicia va a costar al menos  60 millones  extra.  Pero como el dinero sale del bolsillo de los ciudadanos, pues aquí no pasa absolutamente nada y nadie asumirá ninguna responsabilidad. Esta es la triste realidad de la España actual. Pero es que hasta un trámite tan sencillo como pedir cita previa en una de las Jefaturas Provinciales de Tráfico desespera hasta al más templado. Y como quiero ser muy específico y una imagen vale más que mil palabras, a continuación voy a documentar todo el proceso que es de todo menos intuitivo. Todo empieza abriendo este enlace Y como podéis ver en la imagen previa, con la primera pantalla (vamos a obviar que la interfaz parece que ya haya cumplido la mayoría de edad, tiene pinta de ser de finales de los 90) llega la pri
Post a Comment
Read more

Proof of Social Network Identity: a proof of concept

One of the main criticisms to blockchain technology is based on the huge consumption of electricity required by the biggest networks (e.g., Bitcoin and Ethereum). That huge electric power consumption  comes from using Proof of Work (PoW) algorithms to prevent " double spending " which is closely related to the " 51% attack ". Some other types of algorithm have been developed as an alternative to PoW, the more popular one being Proof of Stake (PoS), which basically implies that individuals with higher stake (i.e., more crypto money) have more power (i.e., are more trusted) than the rest. Hence, PoS, creates an entry barrier for those who want to become members of the blockchain network, since one needs to own a stake in order to join the network. The key to prevent " double spending / 51% attacks"  is to use something  in the block validation mechanism which is complicated or expensive enough for some malicious actor to replicate or to clone or
Post a Comment
Read more