Événements envoyés par le serveur vs interrogation
Existe-t-il une grande différence (en termes de performances, de disponibilité d'implémentation du navigateur, de charge du serveur, etc.) entre HTML5 SSEs et l'interrogation Ajax directe? Du côté serveur, il semble qu'un EventSource frappe juste la page spécifiée toutes les ~ 3 secondes environ (bien que je comprenne que le timing est flexible).
Certes, il est plus simple à configurer côté client que de configurer un minuteur et de l'avoir $.get de temps en temps, mais y a-t-il autre chose? Envoie-t-il moins d'en-têtes ou fait-il une autre magie qui me manque?
L'interrogation Ajax ajoute beaucoup de surcharge HTTP car elle établit et supprime constamment des connexions HTTP. Comme le dit HTML5 Rocks "Les événements envoyés par le serveur, en revanche, ont été conçus à partir de zéro pour être efficaces."
Les événements envoyés par le serveur ouvrent une seule connexion HTTP longue durée. Le serveur envoie ensuite unidirectionnellement les données lorsqu'il les a, il n'est pas nécessaire que le client les demande ou fasse autre chose que d'attendre les messages.
Un inconvénient des événements envoyés par le serveur est que, car ils créent une connexion persistante au serveur, vous pouvez potentiellement avoir de nombreuses connexions ouvertes à votre serveur. Certains serveurs gèrent mieux un nombre important de connexions simultanées que d'autres. Cela dit, vous auriez des problèmes similaires avec l'interrogation plus les frais généraux de rétablir constamment ces connexions.
Les événements envoyés par le serveur sont plutôt bien pris en charge dans la plupart des navigateurs , l'exception notable étant bien sûr IE. Mais il y a un couple sur polyfills (et un plugin jQuery ) qui corrigera cela.
Si vous faites quelque chose qui n'a besoin que d'une communication à sens unique, j'irais certainement avec des événements envoyés par le serveur. Comme vous l'avez mentionné, les événements envoyés par le serveur ont tendance à être plus simples et plus propres à implémenter côté client. Il vous suffit de configurer des écouteurs pour les messages et les événements et le navigateur s'occupe des choses de bas niveau comme se reconnecter s'il est déconnecté, etc. Côté serveur, il est également assez facile à implémenter car il utilise simplement du texte simple. Si vous envoyez des objets encodés JSON, vous pouvez facilement les transformer en objets JavaScript sur le client via JSON.parse() .
Si vous utilisez PHP sur le serveur, vous pouvez utiliser json_encode() pour transformer des chaînes, des nombres, des tableaux et des objets en JSON correctement codé. Autre retour -les langages finaux peuvent également fournir des fonctions similaires.
J'ajouterais seulement une perspective plus élevée à ce qui a été dit, et c'est que SSE est un modèle de publication-abonnement par opposition à une interrogation constante dans le cas d'AJAX.
Généralement, les deux méthodes (interrogation et publication-abonnement) tentent de résoudre le problème de la façon de maintenir un état à jour sur le client.
1) Modèle d'interrogation
C'est simple. Le client (navigateur) obtient d'abord un état initial (page) et pour qu'il se mette à jour, il doit périodiquement demander l'état (page ou sa partie) et traiter le résultat dans l'état actuel (actualiser la page entière ou le rendre intelligemment dans son partie en cas d'AJAX).
Naturellement, un inconvénient est que si rien ne se passe avec l'état du serveur, les ressources (CPU, réseau, ...) sont utilisées inutilement. Un autre est que même si l'état change, les clients ne l'obtiennent qu'à la prochaine période d'interrogation, pas dès que possible. Il faut souvent évaluer un bon compromis période-temps entre les deux choses.
Un autre exemple d'interrogation est un spinwait dans le threading.
2) Modèle de publication-abonnement
Cela fonctionne comme suit:
- (le client demande d'abord et montre un état initial)
- le client s'abonne au serveur (envoie une demande, éventuellement avec un contexte comme une source d'événement)
- serveur marque la référence au client à certains de son référentiel de référence client
- en cas de mise à jour de l'état, le serveur envoie une notification au client sur la base de la référence au client qu'il détient; c'est-à-dire qu'il ne s'agit pas d'une réponse à une demande mais d'un message initié par le serveur
- les bons clients se désabonnent lorsqu'ils ne sont plus intéressés par les notifications
Il s'agit de SSE, ou de thread d'un événement en attente, comme autre exemple. Un inconvénient naturel, comme indiqué, est que le serveur doit connaître tous ses clients abonnés qui, selon une implémentation, peuvent être un problème.