Implémentation de la technologie push à l'aide d'événements de serveur

Points de base

• L'API des événements de serveur (SSE) implémente la technologie push et les données sont diffusées vers le client via des connexions ouvertes continues, en évitant les frais généraux d'établir à plusieurs reprises de nouvelles connexions.
• Contrairement à WebSockets qui permettent une communication bidirectionnelle, SSE permet uniquement au serveur de pousser les messages au client. Cependant, SSE présente certains avantages, tels que la prise en charge des types de messages personnalisés et la reconnexion et la déconnexion automatique.
• Les clients peuvent gérer divers types d'événements dans le flux d'événements en mettant en œuvre des événements nommés. De plus, le gestionnaire d'événements onerror de Eventsource peut être utilisé pour gérer les erreurs, et le client peut terminer la connexion EventSource à tout moment en appelant la méthode close().

Comparaison avec WebSockets

Beaucoup de gens ignorent complètement l'existence des SSE, car ils sont souvent obscurcis par l'API les plus puissants WebCoChets. Bien que WebSockets autorise la communication complète bidirectionnelle entre le client et le serveur, SSE permet uniquement au serveur de pousser les messages au client. Les applications qui nécessitent des performances en temps proche ou une communication bidirectionnelle peuvent être plus adaptées aux websockets. Cependant, SSE présente également certains avantages par rapport à WebSockets. Par exemple, SSE prend en charge les types de messages personnalisés et la déconnexion de reconnexion automatique. Ces fonctionnalités peuvent être implémentées dans WebSockets, mais elles sont disponibles par défaut dans SSE. L'application WebSockets nécessite également un serveur qui prend en charge le protocole WebSockets. En revanche, SSE est construit sur HTTP et peut être implémenté dans un serveur Web standard.

Prise en charge de détection

SSE est relativement élevé en matière de soutien, et Internet Explorer est le seul navigateur majeur qui ne les soutient pas encore. Cependant, tant que IE est en retard, une détection fonctionnelle est toujours nécessaire. Sur le client, SSE utilise l'objet Eventsource pour implémenter: une propriété de l'objet global. La fonction suivante détecte si le constructeur EventSource est disponible dans le navigateur. Si la fonction renvoie true, SSE peut être utilisée. Sinon, un mécanisme de sauvegarde tel que le sondage doit être utilisé.

function supportsSSE() {
  return !!window.EventSource;
}

connexion

Pour vous connecter au flux d'événements, appelez le constructeur Eventsource comme indiqué ci-dessous. Vous devez spécifier l'URL du flux d'événements pour vous abonner. Le constructeur sera automatiquement responsable de l'ouverture de la connexion.

EventSource(url);

onopen Handler d'événements

Après avoir établi la connexion, le gestionnaire d'événements onopen de Eventsource sera appelé. Le gestionnaire d'événements ouvre l'événement comme seul paramètre. L'exemple suivant montre un gestionnaire d'événements commun onopen.

source.onopen = function(event) {
  // 处理打开事件
};

Le gestionnaire d'événements

eventsource peut également être écrit en utilisant la méthode addEventListener(). Cette syntaxe alternative est meilleure que onopen car elle permet de fixer plusieurs gestionnaires à la même événement. Le suivant utilise addEventListener() pour réécrire le gestionnaire d'événements onopen précédent.

source.addEventListener("open", function(event) {
  // 处理打开事件
}, false);

Recevoir le message

Le client interprète le flux d'événements en tant que série d'événements de message DOM. Chaque événement reçu du serveur déclenche le gestionnaire d'événements onmessage pour Eventsource. onmessage Le gestionnaire prend l'événement de message comme son seul paramètre. L'exemple suivant crée un gestionnaire d'événements onmessage.

function supportsSSE() {
  return !!window.EventSource;
}

Les événements de message contiennent trois propriétés importantes - Données, Origine et LaserEntid. Comme son nom l'indique, les données contient les données du message réelles (format de chaîne). Les données peuvent être une chaîne JSON et peuvent être transmises à la méthode JSON.Parse (). La propriété Origin contient l'URL finale du flux d'événements après toute redirection. L'origine doit être vérifiée pour vérifier que les messages sont reçus uniquement de la source attendue. Enfin, la propriété LaserEntid contient le dernier identifiant de message vu dans le flux d'événements. Le serveur peut utiliser cette propriété pour ajouter un identifiant aux messages individuels. Si aucun identifiant n'a été vu, LaserEntid sera une chaîne vide. Le gestionnaire d'événements onmessage peut également être écrit en utilisant la méthode addEventListener(). L'exemple suivant montre le gestionnaire d'événements addEventListener() qui a été réécrit à l'aide de onmessage.

EventSource(url);

Événement de dénomination

En implémentant Name Event , un seul flux d'événements peut spécifier divers types d'événements. Les événements nommés ne sont pas gérés par le gestionnaire d'événements de message. Au lieu de cela, chaque type d'événement de dénomination est géré par son propre gestionnaire unique. Par exemple, si le flux d'événements contient un événement nommé FOO, le gestionnaire d'événements suivant est requis. Notez que le gestionnaire d'événements FOO est le même que le gestionnaire d'événements de message, sauf que le type d'événement est différent. Bien sûr, tout autre type de messages nommés nécessite un gestionnaire d'événements distinct.

source.onopen = function(event) {
  // 处理打开事件
};

Erreur de traitement

S'il y a un problème avec le flux de l'événement, le gestionnaire d'événements onerror pour Eventsource sera déclenché. Une cause courante d'erreurs est l'interruption de la connexion. Bien que l'objet EventSource essaie automatiquement de se reconnecter au serveur, un événement d'erreur sera également déclenché lorsque la connexion est déconnectée. L'exemple suivant montre un gestionnaire d'événements onerror.

source.addEventListener("open", function(event) {
  // 处理打开事件
}, false);

Bien sûr, le gestionnaire d'événements onerror peut également être réécrit à l'aide de addEventListener() comme indiqué ci-dessous.

source.onmessage = function(event) {
  var data = event.data;
  var origin = event.origin;
  var lastEventId = event.lastEventId;
  // 处理消息
};

Débrancher

Le client peut résilier la connexion EventSource à tout moment en appelant la méthode close(). La syntaxe de close() est illustrée ci-dessous. La méthode close() n'accepte aucun paramètre et ne renvoie aucune valeur.

source.addEventListener("message", function(event) {
  var data = event.data;
  var origin = event.origin;
  var lastEventId = event.lastEventId;
  // 处理消息
}, false);

Statut de connexion

Le statut de la connexion Eventsource est stocké dans sa propriété ReadyState. À tout moment de son cycle de vie, une connexion peut être dans l'un des trois états possibles - dans, sur et hors et off. La liste suivante décrit chaque état.

• Connexion - Lorsqu'un objet Eventsource est créé, il entrera initialement dans l'état de connexion. Au cours de cette période, la connexion n'a pas été établie. Si une connexion établie est perdue, Eventsource passera également à l'état de connexion. La valeur ReadyState de EventSocket dans la connexion est 0. Cette valeur est définie comme la constante Eventsource.connecting.
• Open - Une connexion établie est appelée ouverte. Un objet Eventsource qui est ouvert peut recevoir des données. La valeur prêt à l'emploi de 1 correspond à l'état ouvert. Cette valeur est définie comme la constante Eventsource.open.
• Close - Si une connexion n'est pas établie et qu'une reconnexion n'est pas tentée, l'événement est appelé fermé. Cet état est généralement entré en appelant la méthode close(). La valeur prêt à l'emploi de l'événement Cource dans un état fermé est de 2. Cette valeur est définie comme la constante Eventsource.Closed.

L'exemple suivant montre comment vérifier une connexion EventSource à l'aide de la propriété ReadyState. Pour éviter les valeurs prêtes à code dur, cet exemple utilise des constantes d'état.

function supportsSSE() {
  return !!window.EventSource;
}

Conclusion

Cet article présente les aspects du client de SSE. Si vous souhaitez en savoir plus sur SSE, je vous recommande de lire le serveur SSE. J'ai également écrit un article plus pratique sur SSE dans Node.js. apprécier!

Les questions fréquemment posées sur l'utilisation de SSE pour mettre en œuvre la technologie push (FAQ)

Quelles sont les conditions préalables à la mise en œuvre de SSE?

Pour implémenter SSE, vous avez besoin d'une compréhension de base de JavaScript et Node.js. Vous devriez également être familier avec le concept de HTTP et son fonctionnement. En outre, la compréhension de la programmation axée sur les événements peut être bénéfique car SSE est basée sur ce concept.

En quoi SSE est-il différent de WebSockets?

Alors que SSE et WebSockets fournissent des mises à jour de données en temps réel, leurs capacités et leurs cas d'utilisation varient. WebSockets fournit un canal de communication bidirectionnel entre le client et le serveur, permettant aux deux parties d'envoyer des données à tout moment. D'un autre côté, SSE est un canal de communication à sens unique où seul le serveur peut pousser les mises à jour du client. Cela rend SSE plus adapté aux applications où les mises à jour de données sont principalement lancées par des serveurs.

peut-il être utilisé avec n'importe quelle langue côté serveur?

Oui, SSE peut être utilisé avec n'importe quel langage côté serveur compatible HTTP. Cela inclut des langues telles que Node.js, Python, PHP et Ruby. La clé consiste à définir l'en-tête HTTP correct et à formater les données en fonction de la spécification SSE.

Comment gérer les erreurs de connexion ou les interruptions dans SSE?

L'API EventSource utilisée pour implémenter SSE sur le client tentera automatiquement de se reconnecter au serveur lorsque la connexion sera perdue. Vous pouvez également écouter l'événement "Erreur" sur l'objet Eventsource pour gérer manuellement les erreurs de connexion ou les interruptions.

Puis-je utiliser SSE pour envoyer des données du client au serveur?

Non, SSE est destiné à la communication unidirectionnelle du serveur au client. Si vous avez besoin d'envoyer des données du client au serveur, vous pouvez utiliser des demandes AJAX traditionnelles ou passer à des technologies de communication bidirectionnelles, telles que WebSockets.

SSE prend-il en charge tous les navigateurs?

La plupart des navigateurs modernes prennent en charge SSE. Cependant, Internet Explorer ne prend pas en charge SSE. Vous pouvez utiliser des polyfills comme Eventsource.js pour ajouter la prise en charge de SSE dans des navigateurs non pris en charge.

Comment fermer la connexion SSE?

Vous pouvez fermer la connexion SSE en appelant la méthode close() sur l'objet Eventsource. Cela empêchera le serveur d'envoyer plus de mises à jour au client.

Puis-je utiliser SSE pour des applications en temps réel multi-utilisateurs?

Oui, vous pouvez utiliser SSE pour les applications multi-utilisateurs en temps réel. Cependant, n'oubliez pas que chaque utilisateur ouvre une connexion distincte au serveur. Si vous avez un grand nombre d'utilisateurs, cela peut entraîner une charge de serveur excessive.

Comment utiliser SSE pour envoyer différents types d'événements?

Vous pouvez envoyer différents types d'événements en incluant le champ "Event" dans les données envoyées du serveur. Le client peut ensuite écouter ces types d'événements spécifiques à l'aide de la méthode addEventListener() sur l'objet Eventsource.

Puis-je utiliser SSE avec API REST?

Oui, vous pouvez utiliser SSE avec l'API REST. Le serveur peut envoyer des mises à jour au client lorsque la ressource change. Ceci est utile pour garder le client et l'état du serveur synchronisé sans sondage.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!