Ignora Angular.js en esta discusión (es irrelevante). Esto es cierto para cualquier cliente basado en navegador web (Ember, Knockout, React, jQuery, etc.).
Socket.IO es un marco para simplificar el uso de Websockets en el navegador y con Node.js como servidor de servidor web. Socket.IO se utiliza para la comunicación en tiempo real entre un navegador y un servidor web utilizando un paradigma reactivo de programación (controlado por eventos). Si desea persistencia, enrutamiento, garantías transaccionales, seguridad, etc., debe integrarlo en su aplicación (ese no es el propósito de Socket.IO).
El papel de RabbitMQ en arquitectura es diferente al de Socket.IO. RabbitMQ es un agente de mensajes. Este es un servidor (o grupo de servidores) dedicado a mediar la comunicación entre uno o más componentes a través de “mensajes”. RabbitMQ admite varios protocolos basados en TCP, incluidos AMQP, MQTT, STOMP y WebSockets (sí, podría utilizar el cliente de Socket.IO con RabbitMQ). Los corredores de mensajes generalmente ofrecen una serie de características, que incluyen colas duraderas (los mensajes persisten hasta que se consumen), garantías de transacción en la entrega, enrutamiento avanzado y seguridad (en el contexto de enviar y recibir mensajes). En general, los corredores de mensajes median la comunicación entre servidores y / o “clientes ricos” (aplicaciones de escritorio). Estos clientes no suelen utilizar Websockets (por lo tanto, Socket.IO) para comunicarse.
- ¿Puedes aprender todo el desarrollo web en video?
- ¿Qué tan bueno es Python para construir una aplicación GUI con una base de datos?
- ¿Qué empresas en Londres tienen la mejor cultura de JavaScript / Node.js?
- ¿Qué es mejor para crear un sitio web social, Ruby on Rails o el sitio oficial de Microsoft ASP.NET? ¿Por qué?
- ¿Cuál tiene un futuro mejor: web2py o Ruby on Rails?
Las arquitecturas modernas a menudo emplean servidores web que usan Websockets (Socket.IO) y Message Brokers (RabbitMQ, Kafka, ZeroMQ, ApacheMQ, etc.) juntos. Los servidores web se conectarán a un intermediario de mensajes y reenviarán los mensajes procedentes de los servicios del backend al navegador a través de Websockets. Este es un paradigma increíblemente poderoso, ya que permite a los clientes (como un navegador web) iniciar solicitudes (a través de sockets web) que potencialmente podrían devolver más de una respuesta de la arquitectura. Más importante aún, las respuestas no necesariamente tienen que estar relacionadas y pueden regresar cada vez que se cumplen (no necesariamente hay un tiempo de espera porque el servidor web tardó demasiado en proporcionar los resultados).
Por ejemplo, un navegador web podría enviar una “solicitud de búsqueda” a través de sockets web al servidor web. El servidor web recibiría la solicitud y reenviaría el mensaje al intermediario de mensajes. Un servicio de búsqueda de texto y un servicio de búsqueda de imágenes podrían recibir la solicitud y ejecutar búsquedas en sus motores de búsqueda subyacentes. El servicio de texto e imagen enviaría sus resultados al intermediario de mensajes donde el servidor web los consumiría y reenviaría los mensajes al navegador (a través de sockets web). Además, un servicio de recomendaciones podría ver los resultados de búsqueda de texto devueltos y enviar recomendaciones basadas en los 10 artículos principales.
La moraleja de esta historia es que te has topado con un tema mucho más grande de lo que esperabas. Debería consultar: Procesamiento de eventos en acción y, en general, leer sobre arquitecturas controladas por eventos.
