Vert.x

An open-source polyglot platform or toolkit is referred to as Vert.x in Java. The Vert.x platform runs on JVM(Java Virtual Machine). We can say that it is an alternative to the JEE. It comes with a different approach in the market to solve the issues such as developing networked and highly concurrent applications. It shares common functionalities among all the supported languages like Java, Ruby, Kotlin, Scala, and JavaScript.

Vert.x is a toolkit, so we can embed it into our standalone Java application. We can use it by instantiating the object of Vert.x and calling the method on it. In toolkit mode, our code control vert.x. It also acts as a platform, so we can set up it using the command line and tell the components to it which want to run.

The golden rule

Vert.x is pretty simple to work with, and an http server can be brought up with a few lines of code.

The method request Handler is where the event loop delivers the request event. As Vert.x is un-opinionated, handling it is free style. But keep in mind the single important rule of non-blocking thread: don’t block it.

When working with concurrency we can draw from so many options available today such as Promise, Future, Rx, as well as Vert.x’s own idiomatic way. But as the complexity of an application grows, having async functionality alone is not enough. We also need the ease of coordinating and chaining calls while avoiding callback hell, as well as passing any error gracefully.

Scala Future satisfies all the conditions above with the additional advantage of being based on functional programming principles. Although this article doesn’t explore Scala Future in depth, we can try it with a simple app. Let’s say the app is an API service to find a user given their id:

There are three operations involved: checking request parameter, checking if the id is valid, and fetching the data. We will wrap each of these operations in a Future and coordinate the execution in a “for comprehension” structure.

• The first step is to match the request with a service. Scala has a powerful pattern matching feature that we can use for this purpose. Here we intercept any mention of “/user” and pass it into our service.
• Next is the core of this service where our futures are arranged in a sequential for-comprehension. The first future f1 wraps parameter check. We specifically want to retrieve the id from the get request and cast it into int. (Scala doesn’t require explicit return if the return value is the last line in the method.) As you see, this operation could potentially throw an exception as id might not be an int or not even available, but that is okay for now.
• The second future f2 checks the validity of id. We block any id lower than 100 by explicitly calling Future.failed with our own CustomException. Otherwise we pass an empty Future in the form of Future.unit as successful validation.
• The last future f3 retrieves the user with the id provided by f1. As this is just a sample, we don’t really connect to a database. We just return some mock string.
• map runs the arrangement that yields the user data from f3 then prints it into the response.
• Now if in any part of the sequence an error occurs, a Throwable is passed to recover. Here we can match its type to a suitable recovery strategy. Looking back in our code, we have anticipated several potential failures such as missing id, or id that was not int or not valid which would throw specific exceptions. We are handling each of them in handleException by passing an error message to client.

This arrangement provides not only an asynchronous flow from the start to the end but also a clean approach to handling errors. And as it is streamlined across handlers we can focus on things that matter, like database query.