Ajax vs Socket.io

node.js websocket

Question

Estoy desarrollando una aplicación web y me preguntaba qué método debería ser adecuado para mi proyecto.

Básicamente, lo que quiero mostrar a los usuarios son algunas notificaciones que se toman de las solicitudes a otros servidores. Mi aplicación node.js obtiene toda la información y luego se extiende a los usuarios, guardando una copia en mi MongoDB.

La idea es bastante simple, pero al leer sobre métodos encontré estas dos técnicas:

1. Ajax: el lado del cliente verificaría todo el tiempo si hay contenido nuevo en el servidor. Esto se haría utilizando un jquery ajax llegar a la API de mi servidor (cada 30/60 segundos).

2. Socket.io: el cliente se conecta una vez y luego se mantiene una conexión TCP permanente (más tiempo real).

Ahora que he explicado la situación, tengo las siguientes preguntas:

• ¿No tendría demasiadas solicitudes con ajax? Imagine que quiero un cheque cada minuto al servidor, si escalamos la aplicación a 100 usuarios, me dará 100 consultas por minuto. ¿Sería "más barato" en recursos del sistema tener un socket?

• ¿Sería el socket.io un problema para dispositivos móviles? ancho de banda y rendimiento. La respuesta del servidor siempre es información en formato JSON.

• Leí que now.js podría usarse para esto, pero parece que el proyecto ya no es compatible, por lo que no estoy seguro si usarlo sería una buena idea.

• ¿Cómo es el almacenamiento en caché en ambos métodos? Estaba considerando crear un archivo de caché para cada usuario y esto sería actualizado por el node.js en el lado del servidor. Supongo que esto podría funcionar muy bien con ajax, pero ¿qué pasa con socket.io?

• ¿Es cierto que socket.io no es compatible con muchos navegadores? Mi aplicación estaría más enfocada en dispositivos móviles y creo que esto podría hacerme pensar en elegir ajax.

• ¿Alguna alternativa sugerida?

Espero que esto pueda aclarar mi mente y otras personas que están en la misma situación :) Gracias

Answer 1

Aquí se analizan muchas de las compensaciones genéricas entre webSocket y Ajax:

API websocket vs rest para datos en tiempo real?

Aquí se analizan algunos problemas de compensación para dispositivos móviles:

Cordova: ¿Sockets, PushNotifications o servidor de sondeo repetido?

En pocas palabras, si sus datos se basan principalmente en el servidor y luego deben enviarse a los clientes y desea una latencia bastante buena para cuando los clientes vean los nuevos datos, entonces ese es el problema exacto para el que los WebSockets son buenos. webSockets funciona mejor en esta situación porque el cliente no necesita sondear con frecuencia, el servidor no necesita manejar solicitudes de sondeo regulares de muchos clientes. En cambio, cada cliente simplemente configura un canal de comunicación webSocket persistente que el servidor puede enviar datos a pedido en cualquier momento.

¿No tendría demasiadas solicitudes con ajax? Imagine que quiero un cheque cada minuto al servidor, si escalamos la aplicación a 100 usuarios, me dará 100 consultas por minuto. ¿Sería "más barato" en recursos del sistema tener un socket?

Los sockets requieren muy pocos recursos cuando no están activos, por lo que sí, un webSocket permanente es más eficiente que muchos clientes que realizan encuestas de forma interminable. Por eso se inventaron los webSockets porque son mejores para resolver este problema en particular.

¿Sería el socket.io un problema para dispositivos móviles? ancho de banda y rendimiento. La respuesta del servidor siempre es información en formato JSON.

socket.io no es un problema para el ancho de banda o el rendimiento. Existen algunos problemas móviles al intentar usar webSockets en segundo plano porque los dispositivos móviles también están tratando de hacer una administración activa de energía, aunque también existe un problema similar con el sondeo de clientes.

¿Cómo es el almacenamiento en caché en ambos métodos? Estaba considerando crear un archivo de caché para cada usuario y esto sería actualizado por el node.js en el lado del servidor. Supongo que esto podría funcionar muy bien con ajax, pero ¿qué pasa con socket.io?

¿No está claro qué está preguntando sobre el almacenamiento en caché? En una implementación de webSocket, el servidor obtiene los datos y luego los envía a cada usuario. Generalmente no se necesitaría el almacenamiento en caché del lado del servidor. En una implementación de sondeo de cliente Ajax, el servidor tendría que almacenar los datos en algún lugar y "esperar" a que cada cliente solicite los datos. No existe un mecanismo de almacenamiento en caché "incorporado" para webSocket o Ajax.

¿Es cierto que socket.io no es compatible con muchos navegadores? Mi aplicación estaría más enfocada en dispositivos móviles y creo que esto podría hacerme pensar en elegir ajax.

socket.io es totalmente compatible con todos los navegadores que tienen webSockets, que es prácticamente todo lo que se usa actualmente, excepto IE9 y versiones anteriores. Si usa la biblioteca socket.io, automáticamente recurrirá a un sondeo largo si webSockets no existe. Es probable que sus problemas móviles sean similares, ya sea que realice encuestas regulares o webSocket, ya que el dispositivo móvil desea administrar las cosas de larga ejecución, pero no desea detener las encuestas. No creo que esta sea una razón para evitar webSockets / socket.io. socket.io tiene una lógica de reconexión automática realmente agradable cada vez que pierde la conexión, lo que puede ser realmente útil.

En el mundo móvil, creo que simplemente descubrirá que no puede hacer notificaciones en tiempo real de manera confiable en segundo plano sin usar algún tipo de componente de aplicación nativa que pueda conectarse al sistema nativo "push" en el dispositivo porque ese es el único sistema que es eficiente con la batería y totalmente compatible con la administración de energía. Una página web se administrará con energía tan pronto como no sea la tarea principal o cuando el dispositivo haya estado inactivo.