Las notificaciones en vivo es donde prosperan los Websockets y brindan una gran ventaja sobre AJAX.
Como saben, esto ya se discutió antes ambos al debatir el rol de AJAX (excelente para CRUD, no tanto al sondear) y al comparar Rendimiento de Websocket frente a rendimiento de AJAX (Los Websockets siempre son más rápidos cuando se trata de actualizaciones en vivo).
Sí... puede ahorrar recursos y mejorar el rendimiento (así como futuros problemas de mantenimiento del código) agregando on_update "engancha" al punto de acceso a la base de datos.
La idea es simple:cada vez que una llamada de función actualiza la base de datos MySQL, la solicitud de actualización también se envía a una devolución de llamada. Esa devolución de llamada se encarga de publicar la actualización en el canal correcto.
De esta manera, no sondeará la base de datos MySQL.
Algunas bases de datos ofrecen devoluciones de llamada de actualización y otras no. Creo que MySQL lo hace. Sin embargo, evito estas devoluciones de llamada vinculadas a la base de datos porque son específicas de la base de datos. Es mejor (en mi humilde opinión) agregar la devolución de llamada al punto de acceso a la base de datos en la aplicación, por lo que reemplazar una base de datos no afecta el código base.
No creo que AJAX sea un buen enfoque.
HTTP/2 ayuda a mitigar las deficiencias de AJAX, pero no las resuelve todas.
No sé cuántos clientes espera que estén conectados al mismo tiempo, pero obligar a un cliente a enviar una solicitud cada segundo o dos es muy parecido a un ataque DoS autoinfligido.
Considere esto:si un cliente envía una solicitud AJAX cada dos segundos, con 2000 clientes simultáneos, su servidor deberá responder a 1000 solicitudes por segundo; esto incluye autenticación, consultas de bases de datos y todo ese jazz.
Por otro lado, usando Websockets, con 2000 clientes conectados, tienes 2000 conexiones persistentes sin hacer nada hasta que llega un mensaje. No requiere CPU ni trabajo, solo la memoria de la conexión. No hay estrés en el servidor hasta que se envían los datos reales.
Sí, son más complejos de implementar, pero no son tan difíciles una vez que comienzas. Además, hay muchas bibliotecas y herramientas auxiliares que le quitan gran parte del trabajo de encima.
Los problemas comunes relacionados con el enfoque de Websocket incluyen el manejo de la escala horizontal (a menudo agregando una base de datos o un servicio de publicación/suscripción, como Redis), el orden de los mensajes (que es mejor ignorar cuando sea posible) y las preocupaciones de propagación de datos (¿cuándo marcamos datos como "vistos"? ¿Enviamos los datos completos o solo una notificación indicando que los datos están disponibles? ¿Cuántos canales usamos y cómo dividimos las suscripciones?).
Por lo general, las respuestas son específicas de la aplicación y dependen de la función que está tratando de desplegar, así como del tamaño esperado de su conjunto de datos (si cada respuesta que di en SO fuera un canal, no sería realista mantenerlo).
De todos modos... ¡Buena suerte!
