Vert.x – Uma alternativa poliglota ao Node.js para JVM

Vert.x é um framework para a próxima geração de aplicações assíncronas, escaláveis e concorrentes que tem como objetivo fornecer uma alternativa ao Node.js na JVM. Ele possibilita aos desenvolvedores escreverem suas aplicações em diversas linguagens como por exemplo Javascript, Ruby, Groovy, Java ou mesmo uma mistura de todas elas.

Abaixo um exemplo de como seria um servidor web para conteúdo estático no 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);
  }
}

Internamente, uma instância do vert.x gerencia um pequeno número de threads, uma para cada núcleo disponível no servidor. Cada uma dessas threads basicamente implementa um laço de eventos (event loop). Quando é feito o deploy de uma instância de uma aplicação do vert.x (também chamada de verticle), o servidor seleciona um laço de eventos para esta instância. Quaquer outro trabalho subsequente designado para esta instância será despachado usando esta mesma thread. Como é possível haver milhares de verticles executando simultaneamente, cada laço de eventos é designado para vários verticles ao mesmo tempo.

Os Verticles podem se comunicar com outros verticles sendo executados na mesma instância, ou mesmo em instâncias diferentes do vert.x, por meio de um barramento de mensagens. Algo semelhante ao modelo de atores da plataforma Erlang. Esta troca de mensagens visa permitir que o sistema escale além da quantidade de núcleos da máquina, sem gerar a necessidade de se execitar código verticle em vários threads concorrentemente.

O barramento de mensagens é distribuido e engloba não apenas o servidor, mas também o código JavaScript no cliente para aplicações web em "tempo real".

Além da concorrência e a troca de mensagens, o framework também inclui:

1. servidores e clientes TCP/SSL
2. servidores e clientes HTTP/HTTPS
3. suporte a WebSockets/SockJS

A InfoQ realizou um rápido P&R (Perguntas e Respostas) com o criador do framework, Tim Fox, Engenheiro Sênior da VMWare:

InfoQ: Você pode nos dar uma visão arquitetural do vert.x, e como ele foi construído?

Tim: A base do vert.x é escrita em Java, e daí criamos uma API leve para cada linguagem que iremos suportar. Assim cada linguagem tenha sua própria API, que éidiomática para aquela linguagem em específico. Não expomos diretamente a API Java para as outras linguagens. Isso significa que os programadores Ruby vêem as coisas de uma forma natural para Ruby, e os programadores Javascript, algo mais intuitivo para a linguagem deles, e assim por diante.

InfoQ: Você pode nos descrever um fluxo de trabalho típico para um desenvolvedor utilizando o vert.x, comparado especialmente com a experiência anterior que ele pode ter tido com o Node.js?

Tim: Eu imagino que seja bem próximo ao do node.js. O fluxo de trabalho real varia muito se você está executando localmente ou em um ambiente de nuvem, mas isto não é específico do vert.x.

InfoQ: E quanto a executar aplicações de tempo real na JVM em relação a executar no Node.js, considerando-se atividades como depurarção, monitoração e operações?

Tim: Eu diria que monitoração e operação são preocupações do ambiente em que você executa a aplicação, e não do framework em si. Por exemplo, se você fizer o deploy do vert.x em nuvem, provavelmente seu provedor de nuvem proverá a monitoração para você. Por sinal, alguns membros da comunidade já conseguiram executar o vert.x no Openshift e no Heroku. O esperamos que suporte ao CloudFoundry esteja disponível em breve.

InfoQ: Há algum benchmark que compare o vert.x ao Node.js?

Tim: Não temos nenhum benchmark oficial ainda. Mas andei fazendo alguns pessoalmente, e neles a performance e escalabilidade do vert.x superam em muito a do node.js. Espero publicar alguns benchmarks no lançamento da primeira versão, ou pouco tempo depois.

InfoQ: E como o vert.x se compara ao Netty?

Tim: O Netty é uma biblioteca fantástica de E/S de baixo nível, o vert.x na verdade utiliza o Netty internamente. O vert.x, contudo, é uma plataforma completa para a escrita de aplicações assíncronas. O vert.x também oferece um modelo de componentes, E/S de arquivos, e muitas outras coisas que você não encontrará no Netty. Eu diria que na JVM o vert.x seria comparável com algo como o Akka (que também utiliza o Netty), isto é, trata-se de um framework mais abrangente.

O Vert.x é licenciado sobre a licença Apache 2.0, patrocinado pela VMWare, e as contribuições são aceitas de acordo com os termos do Acordo Individual para Contribuidores da SpringSource (SpringSource Individual Contributor License Agreement).