nodejs: Ajax vs Socket.IO, pros y contras

jquery node.js

Question

Pensé en deshacerme de todas las llamadas Ajax del lado del cliente (jQuery) y usar una conexión de socket permanente (Socket.IO).

Por lo tanto, utilizaría los receptores / emisores de eventos del lado del cliente y del lado del servidor.

Ex. un evento de clic se desencadena por el usuario en el navegador, el emisor del lado del cliente empuja el evento a través de la conexión de socket al servidor. El oyente del lado del servidor reacciona ante el evento entrante y devuelve el evento "hecho" al cliente. El oyente del cliente reacciona ante el evento entrante desvaneciéndose en el elemento DIV.

¿Tiene eso algún sentido? ¿Pros contras?

Answer 1

Enviar mensajes unidireccionales e invocar retrollamadas para ellos puede ser muy complicado.

$.get(''/api'', sendData, returnFunction); es más limpio que socket.emit(''sendApi'', sendData); socket.on(''receiveApi'', returnFunction);

Por eso dnode y nowjs se construyeron encima de socket.io para que todo sea manejable. Evento controlado por eventos pero sin renunciar a las devoluciones de llamadas.

Answer 2

Hay mucha desinformación común en este hilo que es muy inexacta.

TL / DR; ¡WebSocket reemplaza HTTP para aplicaciones! Fue diseñado por Google con la ayuda de Microsoft y muchas otras compañías líderes. Todos los navegadores lo admiten. No hay contras.

SocketIO está construido sobre el protocolo WebSocket ( RFC 6455 ). Fue diseñado para reemplazar AJAX por completo. No tiene problemas de escalabilidad como nunca. Funciona más rápido que AJAX, mientras consume una cantidad de recursos menor.

AJAX tiene 10 años y está construido sobre una única función XMLHTTPRequest JavaScript que se agregó para permitir las devoluciones de llamada a los servidores sin tener que volver a cargar toda la página.

En otras palabras, AJAX es un protocolo de documento (HTTP) con una sola función de JavaScript.

Por el contrario, WebSocket es un protocolo de aplicación que fue diseñado para reemplazar por completo HTTP. Cuando actualiza una conexión HTTP (al solicitar el protocolo WebSocket), habilita la comunicación bidireccional de dúplex completo con el servidor y no implica ningún protocolo de intercambio de manos. Con AJAX, debe habilitar keep-alive (que es lo mismo que SocketIO, solo un protocolo anterior) o forzar nuevos handshakes HTTP, que empantanan el servidor, cada vez que realiza una solicitud AJAX.

Un servidor SocketIO que se ejecuta en la parte superior de Node puede manejar 100.000 conexiones simultáneas en modo keep-alive utilizando solo 4 gb de RAM y una sola CPU, y este límite es causado por el motor de recolección de basura V8, no por el protocolo. Nunca lograrás esto con AJAX, incluso en tus sueños más locos.

Por qué SocketIO es mucho más rápido y consume tantos menos recursos

Las principales razones para esto son, una vez más, que WebSocket fue diseñado para aplicaciones, y AJAX es una solución para permitir aplicaciones sobre un protocolo de documento.

Si te sumerges en el protocolo HTTP y utilizas frameworks MVC, verás que una única solicitud AJAX realmente transmitirá 700-900 bytes de carga de protocolo solo a AJAX a una URL (sin ninguna de tu propia carga útil). En marcado contraste, WebSocket usa alrededor de 10 bytes, o aproximadamente 70x menos de datos para hablar con el servidor.

Dado que SocketIO mantiene una conexión abierta, no hay un saludo de mano, y el tiempo de respuesta del servidor está limitado al tiempo de ida y vuelta o ping al servidor mismo.

Existe una información errónea de que una conexión de socket es una conexión de puerto ; no lo es. Una conexión de socket es solo una entrada en una tabla. Se consumen muy pocos recursos, y un solo servidor puede proporcionar más de 1,000,000 de conexiones WebSocket. Un servidor AWS XXL puede albergar más de 1,000,000 de conexiones SocketIO.

Una conexión AJAX comprimirá / desinflará los encabezados HTTP completos, decodificará los encabezados, codificará los encabezados y activará un hilo del servidor HTTP para procesar la solicitud, nuevamente, porque este es un protocolo de documento; el servidor fue diseñado para escupir documentos una sola vez.

En contraste, WebSocket simplemente almacena una entrada en una tabla para una conexión, de aproximadamente 40-80 bytes. Eso es literalmente eso. No hay votación, en absoluto.

WebSocket fue diseñado para escalar.

En cuanto a que SocketIO está desordenado ... Este no es el caso en absoluto. AJAX es complicado, necesitas promesa / respuesta.

Con SocketIO, simplemente tienes emisores y receptores; ni siquiera necesitan saber sobre el otro; no se necesita un sistema de promesas:

Para solicitar una lista de usuarios, simplemente envíe un mensaje al servidor ...

socket.emit("giveMeTheUsers");

Cuando el servidor esté listo, le devolverá otro mensaje. Tada, terminaste. Entonces, para procesar una lista de usuarios, simplemente diga qué hacer cuando obtiene una respuesta que está buscando ...

socket.on("HereAreTheUsers", showUsers(data) );

Eso es. ¿Dónde está el desastre? Bueno, no hay ninguno :) ¿Separación de preocupaciones? Hecho para ti. ¿Bloquea al cliente para que sepa que tiene que esperar? No tienen que esperar :) Puede obtener una nueva lista de usuarios cada vez ... El servidor podría incluso reproducir cualquier comando de UI de esta manera ... Los clientes pueden conectarse entre sí sin siquiera usar un servidor con WebRTC. .

Sistema de chat en SocketIO? 10 líneas de código Videoconferencia en tiempo real? 80 líneas de código Sí ... Luke ... Únete a mí. use el protocolo correcto para el trabajo ... Si está escribiendo una aplicación ... use un protocolo de aplicación.

Creo que el problema y la confusión provienen de personas que están acostumbradas a usar AJAX y piensan que necesitan todo el protocolo extra de promesa en el cliente y una API REST en la parte de atrás ... Bueno, no es así. :) Ya no es necesario :)

sí, has leído bien ... una API REST ya no es necesaria cuando decides cambiar a WebSocket. RESTO es en realidad obsoleto. si escribe una aplicación de escritorio, ¿se comunica con el diálogo con REST? No :) Eso es bastante tonto.

SocketIO, al utilizar WebSocket hace lo mismo para usted ... puede comenzar a pensar en el lado del cliente como el diálogo simple para su aplicación. Ya no necesita REST, en absoluto.

De hecho, si intenta usar REST mientras usa WebSocket, es tan tonto como usar REST como el protocolo de comunicación para un diálogo de escritorio ... no tiene absolutamente ningún sentido.

¿Qué es eso que dices Timmy? ¿Qué pasa con otras aplicaciones que desean usar su aplicación? Deberías darles acceso a REST? Timmy ... WebSocket ha estado fuera por 4 años ... Simplemente haga que se conecten a su aplicación usando WebSocket, y les permita solicitar los mensajes usando ese protocolo ... consumirá 50 veces menos recursos, será mucho más rápido y 10 veces más fácil para desarrollar ... ¿Por qué apoyar el pasado cuando estás creando el futuro?

Claro, hay casos de uso para REST, pero todos son para sistemas antiguos y obsoletos ... La mayoría de la gente simplemente aún no lo sabe.

Answer 3

Socket.IO utiliza una conexión persistente entre el cliente y el servidor, por lo que alcanzará un límite máximo de conexiones simultáneas según los recursos que tenga en el lado del servidor, mientras que más solicitudes asíncronas Ajax se pueden servir con los mismos recursos.

Socket.IO está diseñado principalmente para conexiones en tiempo real y bidireccionales entre el cliente y el servidor, y en algunas aplicaciones no es necesario mantener conexiones permanentes. Por otro lado, las conexiones asíncronas Ajax deben pasar la fase de configuración de conexión HTTP y enviar datos de encabezado y todas las cookies con cada solicitud.

Socket.IO ha sido diseñado como un servidor de proceso único y puede tener problemas de escalabilidad dependiendo de los recursos del servidor que usted está obligado a.

Socket.IO no es adecuado para aplicaciones cuando es mejor almacenar en caché los resultados de las solicitudes de los clientes.

Las aplicaciones Socket.IO enfrentan dificultades con la optimización de SEO y la indexación de los motores de búsqueda.

Socket.IO no es un estándar ni equivalente a W3C Web Socket API, utiliza la API actual de Web Socket si el navegador es compatible, socket.io creado por una persona para resolver la compatibilidad entre navegadores en aplicaciones en tiempo real y es tan joven, aproximadamente 1 año antiguo. Su curva de aprendizaje, menos desarrolladores y recursos de la comunidad en comparación con ajax / jquery, mantenimiento a largo plazo y menos necesidad o mejores opciones en el futuro pueden ser importantes para los equipos de desarrolladores para hacer que su código se base en socket.io o no.