Novato de aplicaciones en tiempo real - Node.JS + Redis o RabbitMQ -> cliente/servidor ¿cómo?

Question

Soy un novato en el desarrollo de aplicaciones en tiempo real y estoy tratando de entender las innumerables opciones que existen. He leído tantas publicaciones de blog, notas y ensayos que las personas han tenido la amabilidad de compartir. Sin embargo, un problema simple parece no tener respuesta en mi pequeño cerebro. Pensé que otras personas podrían tener los mismos problemas, así que también podría inscribirme y publicar aquí en SO. Aquí va:

Estoy construyendo una pequeña aplicación en tiempo real que es chat asíncrono + otra característica divertida. Herví mis opciones a las siguientes dos opciones:

1. Lamp + RabbitMQ
2. Node.JS + + Redis-bar Sub

Creo que tengo lo básico para comenzar a aprender y la construcción esto afuera. Sin embargo, mis (seriamente n00b) preguntas son:

• ¿Cómo me comunico con el usuario final -> Cliente hacia/desde el servidor en ambos? ¿Sería eso simple javascript largo/infinito sondeo?
• De los dos, ¿cuál podría ser más eficiente de construir y gestionar desde un solo Slice (suponiendo 100 - 1,000 usuarios)?
• ¿Debo construir todo con jQuery en el paradigma de la "vieja escuela" y luego identificar qué pila puede tener más sentido? Solo para que pueda obtener el producto desarrollado como un prototipo y luego 'optimizarlo'. ¿O es escribir en uno sobre el otro más que la mera optimización? (Creo que sí, pero no estoy 100% en esto personalmente)

Espero que esta no sea una pregunta loca y no llame la atención de inmediato. Me encantaría algún comentario constructivo, me encanta esta comunidad!

Gracias.

Answer 1

Arquitectónicamente, ambas opciones son las mismas que almacenar los datos en un servidor de base de datos Oracle para que otra aplicación los recupere.

Tanto RabbitMQ como la solución Redis requieren que sus aplicaciones se conecten a un servidor intermediario que maneja las comunicaciones de datos. Redis se parece más a Oracle, porque se puede usar simplemente como una base de datos persistente con una API de red. Pero RabbitMQ es un poco diferente porque MQ Broker no es realmente responsable de la persistencia de los datos.Si lo configura correctamente y usa las opciones correctas cuando publica un mensaje, entonces RabbitMQ realmente conservará los datos, pero no podrá obtener los datos, excepto como parte del proceso normal de puesta en cola de mensajes. En otras palabras, RabbitMQ es para comunicar mensajes y solo ofrece persistencia como una forma de recuperarse de problemas de red o fallas del sistema.

Sugeriría utilizar RabbitMQ y los lenguajes de programación con los que ya esté familiarizado. Dado que el M en LAMP generalmente se interpreta como MySQL, esto significa que o bien no usaría MySQL en absoluto, o solo lo usaría para el almacenamiento de datos a largo plazo, no para las comunicaciones en tiempo real.

El sitio RabbitMQ tiene una gran cantidad de documentación sobre la creación de aplicaciones con AMQP. Sugiero que después de instalar RabbitMQ, lea los documentos para rabbitmqctl y luego cree un vhost para experimentar. De esta forma, es fácil limpiar sus experimentos sin reiniciar todo. También sugiero usar solo intercambios de temas porque puedes emular el comportamiento de intercambios directos y de fanout usando comodines en la clave de enrutamiento. Recuerde, solo publica mensajes en intercambios y solo recibe mensajes de colas. El intercambio es responsable del patrón que coincide con la clave de enrutamiento del mensaje con la clave de enlace de la cola para determinar qué colas deben recibir una copia del mensaje. Vale la pena aprender todo el modelo de AMQP, incluso si solo planea enviar mensajes a una cola con el mismo nombre que la clave de enrutamiento.

Si está construyendo su cliente en el navegador, y quiere construir un prototipo, entonces debería considerar simplemente usar XHR hoy, y luego pasar a algo como Kamaloka-js, que es una implementación de AMQP pura de JavaScript (el Protocolo AMQ) que es el protocolo estándar utilizado para comunicarse con un intermediario de mensajes RabbitMQ. En otras palabras, contruya con lo que sabe hoy, y luego agilice el proceso, algo que (AMQP) tiene un futuro a largo plazo en su caja de herramientas.

Answer 2

¿Debo construir todo con jQuery en el paradigma de la "vieja escuela" y luego identificar qué pila puede tener más sentido? Solo para que pueda obtener el producto desarrollado como un prototipo y luego 'optimizarlo'. ¿O es escribir en uno sobre el otro más que la mera optimización? (Creo que sí, pero no estoy 100% en esto personalmente)

Esto generalmente se llama RAD (diseño/desarrollo rápido de aplicaciones) y es lo que recomendaría en este momento. Esto le permite construir la prueba de concepto que puede usar para trabajar más tarde para obtener lo que desea que suceda.

En cuanto a cómo hablar con los clientes del servidor, y viceversa, ¿ha leído algo en websockets?

Dada la opción entre programación LAMP o basada en eventos, para lo que está sugiriendo, le diría que vaya con la programación basada en eventos, por lo que nodejs. Pero esa es solo la opinión de un hombre.

Answer 3

Bueno,

lámpara - Apache crear nuevo proceso para cada solicitud. RabbitMQ puede ser útil con muchas funciones. Node.js - Utiliza un solo proceso para manejar todas las solicitudes de forma asincrónica con la ayuda del bucle de eventos. Por lo tanto, no hay creación adicional de procesos generales como apache. Para la aplicación de chat asincrónico, socket.io + Node.js + redis pub-sup es la mejor pila. Ya implementé la notificación en tiempo real usando la pila de arriba.