Mi primera respuesta honesta sobre la información menor que tenemos aquí es: depende .
Podrías usar WebSockets para hacer que la comunicación entre pares funcione, como dijo Philippe en una respuesta anterior. ¡Pero para eso también podrías usar WebRTC!
Puede usar WebSockets para comunicarse sin sobrecarga en cada solicitud. Cada solicitud HTTP (S) requiere que se envíen datos de encabezado, por lo que algunas personas dejaron de usar un estilo HTTP (s) -REST en sus front-end para usar 100% WebSockets para minimizar el uso de ancho de banda y optimizar la velocidad.
- ¿Cómo puedo evaluar la calidad de un script codificado en PHP?
- ¿Qué tipo de aplicación es mejor como primer proyecto favorito para la aplicación asp.net MVC 5 para aprender más sobre MVC y mejorar mis habilidades de desarrollo?
- ¿Cuáles son las aplicaciones en tiempo real del algoritmo de Warshall y Floyd?
- Cómo ejecutar mis consultas 24 x 7 en mi aplicación y obtener continuamente resultados para el mismo
- Terminé los cursos HTML / CSS de Codecademy. ¿Cómo puedo mejorar aún más mis habilidades de HTML / CSS?
Puede usar WebSockets para comunicarse desde el servidor al cliente. Normalmente, un cliente hace una solicitud y el servidor debe responder al respecto. Esto tenía algunas desventajas, principalmente para aplicaciones similares a las de una aplicación de chat, porque requeríamos que los datos estuvieran allí instantáneamente. Si alguien dijo algo, la respuesta debería estar allí instantáneamente, no en un intervalo de votación de más de 5 minutos.
Si necesita datos del back-end, sin el front-end o cualquier otro cliente que lo solicite, WebSockets es una excelente manera de resolver este problema. ¡WebSockets es básicamente la comunicación en tiempo real que ya teníamos, por ejemplo, en los juegos, pero ahora (por un tiempo) también en los navegadores!
En los días en que haríamos que WebSockets funcionara con AJAX + sondeo largo, no eran WebSockets reales, pero al menos así parecía. Abriríamos una conexión al back-end y enviaríamos un “keep-alive” en los encabezados. Si el servidor tuviera que enviar un lote de información (por ejemplo, mensajes de chat), respondería con un XML o JSON con el conjunto completo de mensajes de despacho que recibió del servidor.
El principal problema con esto era que cada cliente tenía que solicitar datos constantemente, no fue instantáneo, ya que el retraso sería de 10 a 20 segundos y el procesamiento de datos en lotes no es algo realmente divertido, por lo que fue un poco difícil para que los principiantes lo usen sin llevar su servidor a 160% de CPU.
