Les notifications en direct sont l'endroit où les Websockets prospèrent et offrent un énorme avantage sur AJAX.
Comme vous le savez, cela a déjà été discuté avant lors du débat sur le rôle d'AJAX (idéal pour CRUD, pas tellement lors de l'interrogation) et lors de la comparaison Performances Websocket vs performances AJAX (Les Websockets sont toujours plus rapides en ce qui concerne les mises à jour en direct).
Oui... vous pouvez économiser des ressources et améliorer les performances (ainsi que les futurs problèmes de maintenance du code) en ajoutant on_update "s'accroche" au point d'accès à la base de données.
L'idée est simple :chaque fois qu'un appel de fonction met à jour la base de données MySQL, la demande de mise à jour est également envoyée à un rappel. Ce rappel est chargé de publier la mise à jour sur le bon canal.
De cette façon, vous n'interrogez pas la base de données MySQL.
Certaines bases de données proposent des rappels de mise à jour et d'autres non. Je pense que MySQL le fait. Cependant, j'évite ces rappels liés à la base de données car ils sont spécifiques à la base de données. Il est préférable (à mon humble avis) d'ajouter le rappel au point d'accès à la base de données dans l'application, de sorte que le remplacement d'une base de données n'affecte pas la base de code.
Je ne pense pas qu'AJAX soit une bonne approche.
HTTP/2 aide à atténuer les défauts d'AJAX, mais il ne les résout pas tous.
Je ne sais pas combien de clients vous vous attendez à être connectés simultanément, mais forcer un client à envoyer une requête toutes les secondes ou deux est très proche d'une attaque DoS auto-infligée.
Considérez ceci :si un client envoie une requête AJAX toutes les deux secondes, à 2 000 clients simultanés, votre serveur devra répondre à 1 000 req/sec - cela inclut l'authentification, les requêtes de base de données et tout ce jazz.
D'un autre côté, en utilisant Websockets, avec 2 000 clients connectés, vous avez 2 000 connexions persistantes qui ne font rien jusqu'à ce qu'un message arrive. Aucun processeur ou travail requis, juste la mémoire de la connexion. Il n'y a aucune contrainte sur le serveur jusqu'à ce que les données réelles soient transmises.
Oui, ils sont plus complexes à mettre en œuvre, mais ils ne sont pas si difficiles une fois que vous avez commencé. En outre, il existe de nombreuses bibliothèques et outils d'assistance qui vous soulagent d'une grande partie du travail.
Les problèmes courants liés à l'approche Websocket incluent la gestion de la mise à l'échelle horizontale (souvent en ajoutant une base de données ou un service pub/sub, tel que Redis), l'ordre des messages (qu'il vaut mieux ignorer lorsque cela est possible) et les problèmes de propagation des données (quand marquons-nous données comme "vues" ? Envoyons-nous toutes les données ou simplement une notification indiquant que les données sont disponibles ? Combien de canaux utilisons-nous et comment répartissons-nous les abonnements ?).
Habituellement, les réponses sont spécifiques à l'application et dépendent de la fonctionnalité que vous essayez de dérouler ainsi que de la taille attendue de votre ensemble de données (si chaque réponse que j'ai donnée sur SO était un canal, il serait irréaliste de la maintenir).
Quoi qu'il en soit... Bonne chance !
