Vert.x – L'alternative Polyglotte de la JVM à Node.js

Vert.x veut répondre aux besoins de la prochaine génération d'applications asynchrones, évolutives et concurrentes et vise à fournir une alternative à Node.js sur la JVM. Il permet aux développeurs d'écrire leur application en utilisant JavaScript, Ruby, Groovy, Java ou un mélange de ces différents langages.

Voici le code d'un serveur web servant des fichiers statique en 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);
  }
}

En interne, une instance vert.x ne gère que très peu de threads, un par coeur disponible. Chacun de ces threads implémente globalement une "event loop" (boucle événementielle). Lorsqu'une instance utilisateur vert.x (aussi appelé "verticle") est déployée, le serveur sélectionne une "event loop" qui sera assigné a cette instance. Chaque tâche qui suivra pour cette instance sera toujours dispatchée sur ce même thread. Puisqu'il y a potentiellement plusieurs milliers de verticles actifs à un instant donné, une seule "event loop" est assignée pour gérer plusieurs verticles à la fois.

Les verticles communiquent entre eux, que ce soit au sein de la même instance vert.x ou non, à l'aide de messages via un bus d'évènements, très similaire au modèle d'acteur proposé par Erlang. Cette communication par messages permet au système une montée en charge sur tous les coeurs disponibles tout en permettant d'écrire le code des verticles en mono-thread.

Le bus d'évènement est distribué et ne s'étend pas seuleument au serveur mais pénètre également le client a l'aide du Javascript, ce qui permet la création d'applications webs "real-time".

Outre les aspects concurrentiels et d'envoi de messages, vert.x fournit également :

• Des clients et serveurs TCP/SSL
• Des clients et serveurs HTTP/HTTPS
• Le support WebSockets/SockJS

InfoQ a rencontré Tim Fox, "Senior Staff Engineer" au sein de VMWare, à propos de vert.x:

InfoQ: Pouvez vous nous présenter l'architecture générale de vert.x ainsi que ses concepts ?

Tim: Le coeur de vert.x est écrit en Java, puis nous avons écrit une fine couche d'abstraction pour chaque langage de la JVM que nous supportons. Ainsi, chaque langage a sa propre API et respecte son paradigme idiomatique. Nous n'exposons pas l'API Java directement pour chaque langage. Cela signifie que les dévelopeurs Ruby codent à la façon Ruby, les développeurs Javascript à la façon Javascript, etc

InfoQ: Pouvez vous décrire le "workflow" typique d'un dévelopeur vert.x et plus particulièrement en comparaison avec l'expérience d'un développeur Node.js ?

Cela sera très semblable à node.js. Le "workflow" dépendra de si vous deployez sur le cloud ou en local. Mais ce n'est pas spécifique à vert.x

InfoQ: Et qu'en est-il du déploiement d'une application 'real-time' sur la JVM comparé a Node.js en particulier sur les points suivants: Debug, monitoring, maintenance ?

Je dirais que le monitoring et la maintenance sont plus du ressort de l'environnement sur lequel vous allez déployer vert.x que de vert.x lui-même. Par exemple, si vous déployez vert.x dans le cloud, votre "provider" va très certainement vous fournir des moyens de monitoring. A ce propos, la communauté Vert.x a déjà déployé Vert.x sur OpenShift et Heroku. Le support pour CloudFoundry viendra très certainement bientôt :)

InfoQ: A-t-on des tests de performance afin de le comparer à Node.js ?

Nous n'en avons pas d'officiel pour le moment. Mais j'ai moi-même effectué quelques tests basiques et vert.x dépasse node.js de loin en performance et en montée en charge. J'espère livrer des benchmarks avec la prochaine livraison ou juste après.

InfoQ: Comment comparez-vous vert.x et Netty ?

Netty est une super librairie IO bas niveau. Vert.x utilise Netty. Mais vert.x est une plateforme complète permettant d'écrire des applications asynchrones. Vert.x propose également un modèle de composant, une API asynchrone pour la lecture de fichiers ainsi que d'autres choses que vous ne trouverez pas dans Netty. Je dirais que dans la sphère JVM, Vert.x rentre en compétition avec, disons, Akka (qui utilise également Netty), i.e. c'est un framework complet.

Vert.x est sous license Apache version 2.0, et sponsorisé par VMware. Les contributions sont gouvernées par la license SpringSource Individual Contributor License Agreement.

Dio Synodinos est un consultant freelance se positionnant sur les technologies Web