vert.x – JVM Polyglot Alternative to Node.js
Here’s how a web server that serves static files looks like in vert.x:
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.
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.
5 in JS, Ruby
13 in Java
Feel free to draw your own conclusions :-).
The same way Rails was before it.
Meanwhile, enterprise software is already making use of mature technologies, that while not as fashionable, are able to deliver the required performance and development support required on the enterprise world.
Node.js brings JS to the server.
I think it's good to have other ways to use Java (or any JVM language) on the server than traditional EJB, ORM,...
I have done a lot of JS on the client-side, but I think it's not very efficient compared to java (or C#,...) because of the lack of static typing and advanced IDE support (that's why GWT or Dart were created after all).
Ben Linders May 28, 2015