ruby on rails - EventMachine vs Node.js

ruby-on-rails event-driven

Question

Voy a desarrollar un sitio colaborativo, y una de las características será la edición colaborativa con cambios en tiempo real. es decir, cuando dos o más usuarios están editando el mismo documento, pueden ver los cambios entre ellos tan pronto como ocurren. Tengo algo de experiencia con Ruby on Rails, así que estaba pensando en usar EventMachine, pero con todo este bombo alrededor de Node.js, sé que estoy considerando usarlo. Entonces, ¿cuáles serían los principales beneficios de usar Node.js en lugar de EventMachine?

tl; dr ¿Cuáles son las principales diferencias entre EventMachine y Node.js (además del idioma)?

Answer 1

EventMachine no tiene nada que ver con Rails, aparte de que ambos están escritos en el mismo idioma. Puede obtener EventMachine tan desnudo como Node.js; todo lo que tiene que hacer es no agregar bibliotecas a su proyecto. En mi experiencia, las bibliotecas EventMachine (como em-http) son mucho más agradables para Node. Y puede utilizar fibras en lugar de devoluciones de llamada para evitar el infierno de devolución de llamada. El manejo completo de excepciones es prácticamente imposible en Node debido a todas las devoluciones de llamada. Además, Ruby es un lenguaje mejor y más completo que Javascript.

Answer 2

Tiendo hacia el "uso de lo que sabes" (incluso si es una arquitectura más pesada). Debido a eso, no veo que sea tan simple como "EventMachine vs NodeJS". Principalmente, la diferencia se puede resumir así:

• NodeJS es un marco / lenguaje que fue escrito para manejar la programación basada en eventos en JavaScript. Esa es su fuerza motriz. No es un pensamiento posterior, o un mecanismo de terceros. Está directamente en el idioma. Se crean devoluciones de llamada / eventos porque así se construye el idioma. No es un complemento de terceros y no altera el flujo de trabajo.
• EventMachine es una joya en Ruby que brinda a los desarrolladores acceso a algunas de las bondades del modelo de programación basado en eventos. Es muy usado y probado, pero no está directamente relacionado con el idioma. Ambos están bloqueados a una CPU, pero con la programación de eventos en el núcleo de los nodos, todavía tiene una ventaja. Ruby no fue escrito teniendo en cuenta la concurrencia.

Dicho esto, los problemas técnicos pueden ser superados. Las preguntas más importantes (desde mi punto de vista) que deberían guiar su decisión son las siguientes:

• ¿Cómo será tu entorno de producción? ¿Tienes control completo sobre el servidor? ¿Puedes alojarlo como quieras? O, para empezar, ¿estará en un sistema compartido y luego tendrá que ampliarlo?
• ¿Todos los desarrolladores de su equipo tienen la capacidad de aprender un nuevo idioma muy rápido? ¿Qué tan rápido podrán entender un lenguaje basado en eventos como JavaScript para el nivel medio?
• ¿Necesita toda la arquitectura que Rails le brinda (marco de prueba completo, andamios, modelos, controladores, etc.)? ¿O es una exageración?

Hay bastantes diferencias técnicas entre los dos. Uno es un lenguaje, uno es un marco. Realmente, ¿qué tan pesado de una pila quieres correr? ¿Cuánto aprendizaje tendrán que hacer tus desarrolladores? ¿Quieres una pila completa? Te da muchas sutilezas, que no puedes usar, o quieres una configuración básica que sea extremadamente rápida y concurrente, incluso aunque tengas que escribir un código de placa de caldera adicional y aprender un nuevo idioma?

Si bien Rails no es tan pesado como algunas arquitecturas de aplicaciones web, aún necesitará más potencia de procesador de la que necesitaría para manejar una cantidad similar de rendimiento en NodeJS. Asumiendo código de calidad para ambos sistemas. El código incorrecto escrito en cualquier pila evitará que la pila brille. Realmente se reduce a: ¿Realmente quieres aprender una nueva forma de hacer las cosas, o utilizar tu comprensión actual de Ruby para despegar las cosas rápidamente?

Sé que no es realmente una respuesta definitiva, ¡pero espero que esto te ayude a tomar una decisión!

Answer 3

Una cosa que vale la pena mencionar es la historia de la producción. EM, como la mayoría de Rack stuff, tiene muchas herramientas de prueba y monitoreo disponibles que están bien probadas, mientras que Node.js se queda corto en este aspecto.

En el momento de escribir esto, parece casi imposible obtener métricas claras de Node para responder preguntas como ''Necesito escalar''. Hay opciones que comienzan a formarse a partir de los gustos de Joyent, y siempre el argumento de rollo propio, pero nada en absoluto cerca de herramientas como NewRelic.

Node.js es muy bueno desde el punto de vista de rendimiento / configurabilidad, pero personalmente no lo alojaría en producción por el momento .

Answer 4

una vista detallada en confusión ya ha sido propuesta ... solo una vista personal

[] node.js será mejor si está listo para aprender y experimentar más de lo que cree porque:

• su mecanismo de hilo es impresionante (inspirado en el de ''erlang'')

• puede construir un servidor específico (fácilmente) que será realmente productivo

Answer 5

Node.js

Obtendrá un mejor control del control de bajo nivel sobre lo que está ocurriendo. Puede incluir bibliotecas generales para construir en la parte superior de node.js para ajustar su nivel de abstracción a su gusto. Por ejemplo, puede usar connect o express dependiendo de si desea un motor de visualización escrito para usted. Puede usar socket.io o ahora, dependiendo de cuánto desee abstraer su conexión cliente-servidor. Puede optar por incluir cualquiera de las numerosas bibliotecas MVC o escribir la suya propia.

Máquina de eventos

Una biblioteca de E / S asíncrona como node.js

Todo se reduce a una preferencia de Ruby vs JavaScript, cuánta flexibilidad desea con las abstracciones o la falta de abstracciones y si desea utilizar el nodo como su servidor web real.