SpringMVC vs. Vert.x

What is Vert.x?

Vert.x is an event-driven, non-blocking reactive application framework running on the JVM. Vert.x is polyglot, which means that it supports many different programming languages. Currently are supported: Java, JavaScript, Ruby, Python, Groovy, Scala and more. Vert.x is known for its easy scalability and lightweight architecture which results in very good performance. Vert.x uses Netty for all IO-related processes.

What is special about Vert.x?

When you deal with web applications, you usually handle every single request in its own thread. This results in a lot of threads, most of them blocked, which can create much overhead. Vert.x approaches this problem by creating a fixed number of threads (event loops, mostly equivalent to the number of available CPU cores) which handle the requests using an event-based system. This means, everything works with event handlers and callbacks and you are not supposed to do any thread-blocking work directly in those threads. Instead you register a callback to be called after the task has finished.

How does it work?

You can create so-called „verticles“ which contain your application’s main entry point. Your application can consist of multiple verticles. These verticles are executed within a Vert.x instance and managed by an event loop. The Vert.x instance is running directly on the JVM. Now let us assume that the verticle registered a listener to wait for requests.


At every loop the event loop checks if there are requests available for the verticle. If so, the event loop calls the verticle’s event handler synchronously. The event loops are managed by the Vert.x instance. Usually, you have one event loop running for each processor core with one verticle running on each event loop. But you are free to start more event loops or assign more verticles to one loop. The verticles are connected by an event bus, which they use to send and receive their data. The bus also provides an interface to communicate with each other, even across multiple Vert.x instances or in a cluster. For most usually blocking tasks you can install special busmods (e.g. a MongoDB Persistor) instead of using the usual (blocking) database connectors. If there is no busmod available, you can start worker threads which work asynchronously to the event loops. But if you have to start a worker thread for every request, you should probably use a different framework. You are not supposed to run blocking tasks synchronously, because they would slow down or even block the entire event loop.

How does it look like?

This is how Vert.x looks like with Java:

public class Demo {
  public static void main(String... args) {
    Vertx vertx = Vertx.vertx();
    vertx.createHttpServer().requestHandler(req -> {
      if (req.method() == HttpMethod.GET) {
        if (req.path().equals("/hello")) {
          req.response().end("Hello world.");

As you can see, you add a request handler to your verticle. Then this handler will be invoked by the event loop for every request. After that you filter the requests (e.g. by HttpMethod and path) and respond. You also have to start your HTTP server.

This is how Spring MVC and Spring Boot looks like:

public class Demo {
  public static void main(String... args) {
    SpringApplication.run(Demo.class, args);

  @RequestMapping(value = "/hello", method = RequestMethod.GET)
  public String helloworld() {
    return "Hello world.";

With Spring, you register your request handler by creating a method and annotate it the way you want it to work. The requests are automatically filtered for you. Spring Boot also does the server setup per default on port 8080 for you. Of course you can customize this behavior.

The difference is here that Spring Boot provides defaults which allow you an easy start and get fast results. Spring MVC combined with Spring Boot has a higher usability and an easier readability in general. Also, you do not have to understand all that is going on in the background to create your Hello World application.

What should I use?

That depends on your use case and your personal preferences. If you like annotations and are familiar with Spring, you might not need to learn Vert.x. If you need some exorbitant performance, you should consider Vert.x. Spring Boot handles every request in its own thread which might be appropriate, if you have to handle complex business logic at many requests. In Vert.x you would have to start worker threads for all this which would nullify the performance benefit. But if most of your requests are just requesting semi-dynamic or static web pages anyway, you might be better off with Vert.x performancewise. On the other hand, if you have many shared resources, you could have a very bad time synchronizing them across all your parallel processes in Spring, while Vert.x makes them easier to manage.

SpringMVC is focused on enterprise processes and enterprise applications with lower user counts. Vert.x on the other hand is designed to build your large-scale, super-scalable and distributable web applications which might have less complex business logic in them, but need to perform reliably under massive load. In Vert.x you can deploy or remove verticles dynamically at runtime from your own code to easily adjust your capacity.

If you absolutely want to use Vert.x but do not want to give up on Spring in general, there is always the possibility to integrate Vert.x with your Spring stack, so you can use all the other modules Spring provides.

Short URL for this post: http://wp.me/p4nxik-2Gw
This entry was posted in Java Web Frameworks, Spring Universe and tagged , , , , , . Bookmark the permalink.

2 Responses to SpringMVC vs. Vert.x

  1. Pingback: HTTP/2 Client – Java 9 | techscouting through the java news

  2. Pingback: We are mildly flattered to present a pingback by a plagiarist: HTTP/2 Client – Java 9 – Narasimha Chinimilly

Leave a Reply