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.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/open-source-java-profilers/en/smallimage/unleash-power-of-open-source-java-profilers-small-1681206807197.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/software-delivery-performance-indicators/en/smallimage/software-delivery-performance-indicators-at-different-granularities-small-1684312207072.jpg)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/presentations/dark-energy-matter-microservices/en/smallimage/chris-richardson-small-1684240727275.jpg)
/presentations/techno-solutionism-ethics/en/smallimage/katharine-jarmul-small-1684239823523.jpg)
/articles/learning-ebpf-observability/en/smallimage/learning-eBPF-for-better-observability-small-1684247266792.jpg)
![[R]Evolutionize Your Retrospectives with Active Sensemaking](https://imgopt.infoq.com/fit-in/50x50/filters:quality(80)/articles/retrospectives-active-sensemaking/en/smallimage/revolutionize-your-retrospectives-with-active-sensemaking-small-1684227204199.jpg)
Community comments
Lines
by Roopesh Shenoy,
Re: Lines
by Narayan Bala,
Re: Lines
by arnaud m,
Node.js
by Vic Cekvenich,
Re: Node.js
by Roopesh Shenoy,
Re: Node.js
by Paulo Pinto,
Re: Node.js
by arnaud m,
Security
by Jacob Hookom,
Lines
by Roopesh Shenoy,
Your message is awaiting moderation. Thank you for participating in the discussion.
4 lines in Groovy
5 in JS, Ruby
13 in Java
Feel free to draw your own conclusions :-).
Re: Lines
by Narayan Bala,
Your message is awaiting moderation. Thank you for participating in the discussion.
Just concluded that you've learned to count!!! Kudos
Re: Lines
by arnaud m,
Your message is awaiting moderation. Thank you for participating in the discussion.
Maybe when you write all your code in NotePad,
line count is critical...
:)
Node.js
by Vic Cekvenich,
Your message is awaiting moderation. Thank you for participating in the discussion.
Node.js already does a good job, no need for a java port. Ideally Jave enterprise developers stick w/ EJB or Spring xml configurations, ORM a frameworks, let them be.
Re: Node.js
by Roopesh Shenoy,
Your message is awaiting moderation. Thank you for participating in the discussion.
I maybe wrong, but I think the advantage they are looking for are the ability to use the already mature JVM libraries.
Re: Node.js
by Paulo Pinto,
Your message is awaiting moderation. Thank you for participating in the discussion.
node.js is just the fad of the year technology.
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.
Re: Node.js
by arnaud m,
Your message is awaiting moderation. Thank you for participating in the discussion.
It's funny that while GWT brings Java to the browser to avoid JS,
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).
Security
by Jacob Hookom,
Your message is awaiting moderation. Thank you for participating in the discussion.
In the example above, what would be preventing someone passing a path like '../../../cmd.sh -...' and just blindly executing code or pulling password files?