A typical Vert.x application consists of multiple verticles, which are modules that can be deployed and scaled independently. Verticles communicate with each other by sending messages over an event bus.

Vert.x — Learnings about a reactive framework

Reading Time: 4 minutes

What is Vert.x?

A typical Vert.x application consists of multiple verticles, which are modules that can be deployed and scaled independently. Verticles communicate with each other by sending messages over an event bus. Since Vert.x is a polyglot framework so we can implement each verticle in a different programming language. (currently officially supported languages: Java, JavaScript, Groovy, Ruby, Ceylon, Scala and Kotlin).

Vert.x is unopinionated, which means that it doesn’t restrict you in the way how you want to write your application. The ideal use case for Vert.x is probably an event-driven microservice architecture. We could also use it to build a monolithic application or just include certain Vert.x tools into a Spring application. For example, It’s also very modular, so you can define exactly the tools that you need, and use only these and nothing more, which leads to very lightweight and fast applications that can also run on small hardware.

There is only one important thing that you should always keep in mind. Vert.x is event-driven and non-blocking. So you usually define event handlers, that are called by Vert.x when a certain event occurs. To pass those events to the handlers, Vert.x uses a thread which is called “event-loop. We should never execute any blocking code in your handler because this would also block the event-loop and slow down the whole application. A typical piece of blocking code would be for example a call to a database and waiting for the result. Fortunately Vert.x provides certain ways to handle such cases, like non-blocking clients for some popular databases, or wrapping the blocking code in a special handler.

Pros and cons

Pros

  • The advantage of writing non-blocking code is a performance gain. The application needs to use much fewer threads than a conventional application where usually each request is handled in a separate thread. And fewer threads means less overhead, better CPU usage and better scaling on many parallel requests.

Cons

  • The disadvantage, however, is that non-blocking code is usually a bit more difficult to read, to write and to debug. Although there are of course exceptions. For example, the verticles are threadsafe per default, because they are only accessed by one thread, which can reduce the code complexity in some cases. I also believe that the strict usage of callbacks in an event-driven system of modular verticles automatically encourages decoupling and writing highly cohesive code, which is very good.

But, We always have to be careful that we don’t accidentally include any blocking code, or create a “callback hell” when using many nested callbacks.We should also keep in mind, that you shouldn’t use any libraries that use blocking code, which is the case for most of all third-party libraries. As I already wrote, there are ways to execute blocking code if it really can’t be avoided.

Documentation and community

The official Vert.x documentation is very extensive. It is nicely grouped by topic and with many manuals are and examples in multiple programming languages.These examples are usually kept quite simple, which makes sense I in order to not overwhelm the reader and to focus on one certain tool or use case. However, if you are new to the whole reactive programming style, you might miss some best practices on how to keep your code clean and nicely structured in a bigger and more complex project. On the other side that leaves some room your own creativity.

The community of Vert.x seems to be still relatively small. Examples, there are only 1,523 questions on StackOverflow tagged with Vert.x (compared to 153,358 questions for Spring). The main community channel for Vert.x seems to be a google group with currently 8,921 topics. Although small, the community seems to be very enthusiastic, providing a lot of tutorials, examples, blog posts and additional tools and libraries.

Performance Test Vert.x vs. Spring Boot

Out of curiosity, I created a small test to compare the performance of a simple Vert.x application with a common Spring Boot application. It’s a very basic website, which is just rendering a “Hello World!” string into a Thymeleaf template. There are 2 endpoints, the first is directly returning the result, and the second is simulating a typical case.When we have to retrieve the result from a slow database or another service.

Spring Boot Example:

import java.io.IOException;
import org.apache.catalina.connector.Request;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

@Controller
public class WebController {

    @RequestMapping(value = "/test1",method = RequestMethod.GET)
    public String test1(Model model) throws IOException{
        model.addAttribute("welcome", "Hello Knoldus");
        return "index";
    }
    @RequestMapping(value = "/test2",method = RequestMethod.GET)
    public String test2(Model model) throws  IOException{
        String response = Request.Get("http://localhost:8081").execute()
                .returnContent().asString();
        model.addAttribute("welcome",response);
        return "index";
    }
}

Vert.x Example:

As you can see in the first test, Vert.x is significantly faster compared to Spring Boot. Let’s have a look at the CPU and memory usage during the test:

As expected from a lightweight framework, Vert.x consumes much less CPU and memory over time. But this is just a very simple test case. More interesting is the second test:

Conclusion

There is no framework which is the best for each and every use case. Vert.x is a good choice for an event-driven microservice architecture that can handle many parallel requests in a resource-efficient way.

But, That’s comes with the price of a higher implementation effort. Compared to for example Spring Boot which is often more convenient to use (as you can also see in my little code examples above). Spring Boot also offers some tools for reactive programming, but they are just added to the existing Spring framework (since version 5).Vert.x is completely rooted in the reactive concept. It’s makes it feel much more natural and consequent for me to implement reactive code in Vert.x.

Refrences

knoldus

Written by 

He is a Software Consultant at Knoldus Inc. He has done B.Tech from Dr. APJ Kalam Technical University Uttar-Pradesh. He is passionate about his work and having the knowledge of various programming languages like Java, C++, Python. But he is passionate about Java development and curious to learn Java Technologies. He is always impatient and enthusiastic to learn new things. He is good skills of Critical thinking and problem solving and always enjoy to help others. He likes to play outdoor games like Football, Volleyball, Hockey and Kabaddi. Apart from the technology he likes to read scriptures originating in ancient India like Veda,Upanishad,Geeta etc.