Vert.x - A Primer

Recently, I started working on writing a book about writing Reactive applications using Vert.x. To better help me organize my thoughts and to get early feedback, I have decided to start writing a series of blog posts which will eventually be integrated into that book. You, my dear reader, will get to follow my journey as I try to explain the wonderful and productive world of writing applications with Vert.x. In this first post in the series, I will explain a little about the basic concepts involved with writing Vert.x applications.

Vert.x - A Primer

From the Vert.x website: “Eclipse Vert.x is a tool-kit for building reactive applications on the JVM”. Let’s break that down to better understand what it means.

Toolkit

Unlike many other solutions for Java, Vert.x is not a framework or application server. This means that Vert.x can be used in ANY Java application regardless of it’s structure. You can use Vert.x inside of Spring, JavaEE, Akka, Play!, etc…​ Vert.x is un-opinionated about how you integrate with other libraries/frameworks/platforms, and you can therefore integrate Vert.x with legacy applications and new development.

Reactive

When the Vert.x team talks about Reactive applications, their meaning is reflected in the Reactive Manifesto. The Reactive Manifesto has four major tenets:

• Responsive - The system responds in a timely manner, even when under excessive load.
• Resilient - The system stays responsive even in the event of a failure.
• Elastic - The system stays responsive under varying load and can scale both vertically and horizontally
• Message Driven - Reactive systems rely on asynchronous message-passing to establish boundaries between components.

Polyglot

Merriam-Webster defines polyglot as “speaking or writing several languages”, and in terms of software development the context is very clear: Vert.x applications can be written in a number of languages available for the JVM. These languages include: Java, Groovy, Ruby, JavaScript, Scala, Kotlin, Ceylon, and potentially others. This offers an opportunity for organizations which use Vert.x to have access to more developers with broader experience. Vert.x takes this a step further in that you can actually include code in multiple languages in a single Vert.x application!

Message Driven

Vert.x provides a built-in message passing system known as the Event Bus, and additionally it supports using other external messaging providers. These messaging providers can be used discretely or as a way to extend the Vert.x event bus across multiple disparate systems (Think Python’s Celery or JavaEE’s JMS).

Non-Blocking

Non-blocking I/O is a relatively new concept in the last few years which has gained in popularity as the systems that we develop for have become more parallel in nature. No longer are we writing applications which run on a single CPU with a single pool of memory, we are writing applications which need to take advantage of systems with multiple CPUs and multiple CPU cores in each CPU. To facilitate this applications should be broken down so that discrete operations can run in parallel on different cores. Vert.x uses non-blocking methods to achieve this.

Event Driven

As a corollary to Non-Blocking, Vert.x is designed to be Event Driven. In practice, Vert.x methods and calls are executed asynchronously using callbacks and message passing. This ensures that there should not need to be any threads blocking in the primary execution path (Similar to NodeJS, but we see some differences as we go).

That's it for this first post. Check back again soon for the next in the series!