¿Cuál es la diferencia entre Vert.x y Node.js?
Internamente, una instancia de vert.x gestiona una pequeña colección de subprocesos, uno para cada uno de los núcleos disponibles en el servidor. Básicamente, cada hilo implementa un bucle de eventos. Cuando se implementa una instancia de aplicación de vert.x (también conocida como verticle), el servidor selecciona un ciclo de eventos para asignar a la instancia. Las tareas posteriores para esta instancia se distribuirán a través de este hilo. Dado que puede haber miles de puntos verticales ejecutándose simultáneamente, se asignará un único bucle de eventos a varios puntos verticales simultáneamente.
Los verticales pueden comunicarse con otros verticales que se ejecutan en la misma instancia o en diferentes instancias de vert.x.X a través de un bus de eventos de mensajes, similar al modelo de actor de Erlang. El paso de mensajes está diseñado para permitir que los sistemas escale a través de múltiples núcleos disponibles sin la necesidad de ejecutar código vertical en forma de subprocesos múltiples.
El bus de eventos se distribuye, no sólo a través del servidor, sino que también penetra en el JavaScript del cliente para manejar aplicaciones web "en tiempo real".
Además de simultaneidad y mensajería, vert.x también tiene las siguientes características:
Servidor y cliente TCP/SSL
Servidor y cliente HTTP/HTTPS
Soporte WebSockets/SockJS
InfoQ tuvo la oportunidad de entrevistar a Tim Fox, ingeniero senior de VMWare, para conocer más sobre vert.x:
InfoQ: ¿Puedes decirlo? Cuéntanos un poco sobre vert.x y cómo construirlo.
Tim: Núcleo vertical. x está escrito en Java y luego escribimos una capa API delgada para cada lenguaje JVM compatible, de modo que cada lenguaje tenga una API adecuada para ese lenguaje. No exponemos las API de Java directamente a estos lenguajes. Esto significa que los usuarios de Ruby escribirán código a través de Ruby y los usuarios de JS codificarán a través de JS.
InfoQ: ¿Puede describir el proceso de desarrollo típico en vert.x, especialmente en comparación con la experiencia del desarrollador al usar Node.js?
Creo que esto es muy similar a node.js. El flujo de trabajo real depende de si ejecuta la aplicación localmente o en la nube. Pero esto no es exclusivo de vert.x
InfoQ: ¿Cuáles son las diferencias entre ejecutar aplicaciones en tiempo real en JVM y Node.js en términos de depuración, monitoreo y operaciones?
Me gustaría decir que el monitoreo, la operación y el mantenimiento están en realidad más estrechamente relacionados con el entorno donde se implementa vert.x que el propio vert.x. Por ejemplo, si vert.x está implementado en la nube, el proveedor de la nube puede brindarle monitoreo. Ah, y los miembros de la comunidad ya están ejecutando Vert.x en OpenShift y Heroku. Esperamos que el soporte de CloudFoundry llegue pronto.
infoq: ¿Existe alguna comparación comparativa entre vert.x y Node.js?
No hemos publicado ningún punto de referencia oficial. Pero yo mismo he hecho algunos. En las pruebas que he realizado, vert.x supera con creces a node.js en rendimiento y escalabilidad; con suerte, pronto se publicarán algunas pruebas comparativas.
infoq: ¿Cómo se compara vert.x con Netty?
Netty es una gran biblioteca IO de bajo nivel. Vert.x en realidad usa Netty. Pero vert.x es una plataforma completa para escribir aplicaciones asincrónicas. Vert.x también proporciona un modelo de componente, archivo IO y varias cosas que Netty no tiene. Lo que intento decir es que en el mundo JVM, Vert.x es un marco completo más similar a Akka (que también usa Netty).