vert.x – JVM Polyglot Alternative to Node.js

Vert.x is a framework for the next generation of asynchronous, scalable, concurrent applications, which aims to provide an alternative to Node.js for the JVM. It allows developers to write their application using JavaScript, Ruby, Groovy, Java or even mix and match.

Here’s how a web server that serves static files looks like in vert.x:

// JavaScript
load('vertx.js')
vertx.createHttpServer().requestHandler(function(req) {
  var file = req.path === '/' ? 'index.html' : req.path;
  req.response.sendFile('webroot/' + file);
}).listen(8080)

# Ruby
require "vertx"
Vertx::HttpServer.new.request_handler do |req|
  file = req.uri == "/" ? "index.html" : req.uri
  req.response.send_file "webroot/#{file}"
end.listen(8080)

// Groovy
vertx.createHttpServer().requestHandler { req ->
  def file = req.uri == "/" ? "index.html" : req.uri
  req.response.sendFile "webroot/$file"
}.listen(8080)

// Java
import org.vertx.java.core.Handler;
import org.vertx.java.core.http.HttpServerRequest;
import org.vertx.java.deploy.Verticle;
public class Server extends Verticle {
  public void start() {
    vertx.createHttpServer().requestHandler(new Handler() {
      public void handle(HttpServerRequest req) {
        String file = req.path.equals("/") ? "index.html" : req.path;
        req.response.sendFile("webroot/" + file);
      }
    }).listen(8080);
  }
}

Internally, a vert.x instance manages a small set of threads, one for every available core on the server. Each one of these threads basically implements an event loop. When a vert.x app instance (aka verticle) is deployed, the server chooses an event loop which will be assigned to that instance. Any subsequent work to be done for that instance will always be dispatched using that thread. Since there are potentially many thousands of verticles running at any one time, a single event loop is assigned to many verticles at the same time.

Verticles can communicate with other verticles running in the same, or different vert.x instances using the event bus with messages, something that resembles Erlang’s actor model. Message-passing aims to allow the system to scale over the number of the available cores, without having to allow multi-threaded execution of any verticle code.

The event bus is distributed and does not only span the server, but also penetrates into client side JavaScript for 'real-time' web applications.

Besides concurrency and message-passing, vert.x features include:

• TCP/SSL servers and clients
• HTTP/HTTPS servers and clients
• WebSockets/SockJS support

InfoQ had a small Q&A with Tim Fox, Senior Staff Engineer at VMWare, about vert.x:

InfoQ: Can you give us an architectural overview of vert.x and how it is build?

Tim: The core of vert.x is written in Java, and then we write a thin API shim for each JVM language that we support, so that each language has an API that is idiomatic for that language. We do not expose the Java API directly to each of the languages. This means Ruby users see things done in a Ruby-ish way, JS users see things done in a JS-ish way, etc

InfoQ: Can you describe a typical developer's workflow on vert.x, especially compared the experience that a developer might have with Node.js?

I imagine it is quite similar to node.js. The actual workflow would really depend on whether you're running locally or on a cloud. But it's not really specific to vert.x

InfoQ: What about running a real-time app on the JVM vs. on Node.js, with respect to debugging, monitoring and operations?

I'd say monitoring and operations are really the concern of the environment in which you deploy vert.x than vert.x itself. E.g. if you deployed vert.x in a cloud, the cloud provider would probably provide monitoring for you. BTW, community members have so far got Vert.x running in OpenShift and Heroku. CloudFoundry support coming soon hopefully :)

InfoQ: Are there any benchmarks that compare it with Node.js?

We haven't any official benchmarks yet. But I've done some basic ones privately and vert.x performance and scalability far exceeds node.js in the tests I conducted. I hope to release some benchmarks with the release, or shortly after.

InfoQ: How does vert.x compare to Netty?

Netty is a great low level IO library. Vert.x actually uses Netty. But vert.x is a complete platform for writing asychronous applications. Vert.x also provides a component model, file IO, and various other things you won't find in Netty. I'd say, in the JVM space Vert.x competes more with, say, something like Akka (akka also uses Netty), i.e. it's a complete framework.

Vert.x is licensed under the Apache License version 2.0, sponsored by VMware and contribution is governed by the SpringSource Individual Contributor License Agreement.