Web Sockets, Web Workers, Service Workers… ce sont des termes que vous avez peut-être lus ou entendus. Peut-être pas tous, mais probablement au moins l'un d'entre eux. Et même si vous avez une bonne maîtrise du développement front-end, il y a de fortes chances que vous ayez besoin de rechercher ce qu'ils signifient. Ou peut-être que vous êtes comme moi et que vous les mélangez de temps en temps. Les termes se ressemblent tous et sonnent terriblement et il est très facile de les confondre.
Alors, décomposons-les ensemble et distinguons Web Sockets, Web Workers et Service Workers. Pas dans le sens pratique où nous faisons une plongée profonde et acquérons une expérience pratique avec chacun - plus comme une petite aide pour mettre en signet la prochaine fois I vous avez besoin d'un rafraîchissement.
Référence rapide
Nous commencerons par un aperçu de haut niveau pour une comparaison et un contraste rapides.
| Fonctionnalité | Ce que c'est |
|---|---|
| Prise Web | Établit une connexion bidirectionnelle ouverte et persistante entre le navigateur et le serveur pour envoyer et recevoir des messages sur une seule connexion déclenchée par des événements. |
| Travailleur Web | Permet aux scripts de s'exécuter en arrière-plan dans des threads séparés pour empêcher les scripts de se bloquer mutuellement sur le thread principal. |
| travailleur des services | Un type de Web Worker qui crée un service d'arrière-plan qui agit comme middleware pour gérer les requêtes réseau entre le navigateur et le serveur, même dans des situations hors ligne. |
Prises Web
Un Web Socket est un protocole de communication bidirectionnel. Considérez cela comme un appel continu entre vous et votre ami qui ne se terminera que si l'un de vous décide de raccrocher. La seule différence est que vous êtes le navigateur et votre ami est le serveur. Le client envoie une demande au serveur et le serveur répond en traitant la demande du client et vice-versa.
La communication est basée sur les événements. UN WebSocket objet est établi et se connecte à un serveur, et les messages entre le serveur déclenchent des événements qui les envoient et les reçoivent.
Cela signifie que lorsque la connexion initiale est établie, nous avons une communication client-serveur où une connexion est initiée et maintenue en vie jusqu'à ce que le client ou le serveur choisisse de la terminer en envoyant un CloseEvent. Cela rend Web Sockets idéal pour les applications qui nécessitent une communication continue et directe entre un client et un serveur. La plupart des définitions que j'ai vues appellent les applications de chat comme un cas d'utilisation courant - vous tapez un message, l'envoyez au serveur, déclenchez un événement et le serveur répond avec des données sans avoir à cingler le serveur encore et encore.
Considérez ce scénario: Vous êtes sur le point de partir et vous décidez d'activer Google Maps. Vous savez probablement déjà comment fonctionne Google Maps, mais si vous ne le savez pas, il trouve automatiquement votre position après vous être connecté à l'application et en garde la trace où que vous alliez. Il utilise la transmission de données en temps réel pour garder une trace de votre emplacement tant que cette connexion est active. Il s'agit d'un Web Socket établissant une conversation bidirectionnelle persistante entre le navigateur et le serveur pour maintenir ces données à jour. Une application sportive avec des scores en temps réel peut également utiliser Web Sockets de cette manière.
La grande différence entre les Web Sockets et les Web Workers (et, par extension comme nous le verrons, les Service Workers) est qu'ils ont un accès direct au DOM. Alors que les Web Workers (et les Service Workers) s'exécutent sur des threads séparés, les Web Sockets font partie du thread principal, ce qui leur donne la possibilité de manipuler le DOM.
Il existe des outils et des services pour aider à établir et à maintenir des connexions Web Socket, notamment : Cluster de sockets, API asynchrone, cow-boy, Roi WebSocket, Canauxet Gorille WebSocket. MDN a un liste en cours d'exécution qui comprend d'autres services.
Plus d'informations sur Web Sockets
Travailleurs Web
Considérez un scénario dans lequel vous devez effectuer un tas de calculs complexes tout en apportant des modifications au DOM. JavaScript est une application à thread unique et l'exécution de plusieurs scripts peut perturber l'interface utilisateur à laquelle vous essayez d'apporter des modifications ainsi que le calcul complexe en cours d'exécution.
C'est là que les Web Workers entrent en jeu.
Les Web Workers permettent aux scripts de s'exécuter en arrière-plan dans des threads séparés pour empêcher les scripts de se bloquer les uns les autres sur le thread principal. Cela les rend parfaits pour améliorer les performances des applications qui nécessitent des opérations intensives puisque ces opérations peuvent être effectuées en arrière-plan sur des threads séparés sans affecter l'interface utilisateur du rendu. Mais ils ne sont pas très doués pour accéder au DOM car, contrairement aux Web Sockets, un Web Worker s'exécute en dehors du thread principal dans son propre thread.
Un Web Worker est un objet qui exécute un fichier de script à l'aide d'un Worker s'opposer à l'exécution des tâches. Et lorsque nous parlons de travailleurs, ils ont tendance à appartenir à l'un des trois types suivants :
- Travailleurs dévoués : Un worker dédié n'est accessible que par le script qui l'appelle. Il exécute toujours les tâches d'un travailleur Web typique, telles que ses scripts multi-threading.
- Travailleurs partagés : Un travailleur partagé est le contraire d'un travailleur dédié. Il est accessible par plusieurs scripts et peut pratiquement effectuer n'importe quelle tâche qu'un travailleur Web exécute tant qu'ils existent dans le même domaine que le travailleur.
- Travailleurs des services : Un travailleur de service agit comme un proxy réseau entre une application, le navigateur et le serveur, permettant aux scripts de s'exécuter même en cas de déconnexion du réseau. Nous y reviendrons dans la section suivante.
Plus d'informations sur les travailleurs Web
Travailleurs de service
Il y a certaines choses sur lesquelles nous n'avons aucun contrôle en tant que développeurs, et l'une de ces choses est la connexion réseau d'un utilisateur. Quel que soit le réseau auquel un utilisateur se connecte, c'est ce qu'il est. Nous ne pouvons que faire de notre mieux pour optimiser nos applications afin qu'elles fonctionnent au mieux sur toute connexion utilisée.
Les Service Workers sont l'une des choses que nous pouvons faire pour améliorer progressivement les performances d'une application. Un travailleur de service se trouve entre l'application, le navigateur et le serveur, fournissant une connexion sécurisée qui s'exécute en arrière-plan sur un thread séparé, grâce à - vous l'avez deviné - Web Workers. Comme nous l'avons appris dans la dernière section, les Service Workers sont l'un des trois types de Web Workers.
Alors, pourquoi auriez-vous jamais besoin d'un service worker assis entre votre application et le navigateur de l'utilisateur ? Encore une fois, nous n'avons aucun contrôle sur la connexion réseau de l'utilisateur. Supposons que la connexion échoue pour une raison inconnue. Cela romprait la communication entre le navigateur et le serveur, empêchant les données d'être transmises dans les deux sens. Un service worker maintient la connexion, agissant comme un proxy asynchrone capable d'intercepter les requêtes et d'exécuter des tâches, même après la perte de la connexion réseau.
C'est le principal moteur de ce que l'on appelle souvent développement "hors ligne d'abord". Nous pouvons stocker les actifs dans le cache local au lieu du réseau, fournir des informations critiques si l'utilisateur se déconnecte, prérécupérer les éléments afin qu'ils soient prêts lorsque l'utilisateur en a besoin et fournir des solutions de secours en réponse aux erreurs de réseau. Ils sont entièrement asynchrones mais, contrairement aux Web Sockets, ils n'ont pas accès au DOM puisqu'ils s'exécutent sur leurs propres threads.
L'autre chose importante à savoir sur les Service Workers est qu'ils interceptent chaque demande et réponse de votre application. En tant que tels, ils ont des implications en matière de sécurité, notamment le fait qu'ils suivent une politique de même origine. Cela signifie donc qu'il n'est pas nécessaire d'exécuter un agent de service à partir d'un CDN ou d'un service tiers. Ils nécessitent également une connexion HTTPS sécurisée, ce qui signifie que vous aurez besoin d'un certificat SSL pour qu'ils fonctionnent.
Plus d'informations sur les travailleurs des services
Emballage en place
C'est une explication de très haut niveau des différences (et des similitudes) entre Web Sockets, Web Workers et Service Workers. Encore une fois, la terminologie et les concepts sont suffisamment similaires pour se mélanger les uns aux autres, mais j'espère que cela vous donnera une meilleure idée de la façon de les distinguer.
Nous avons lancé les choses avec un tableau de référence rapide. Voici la même chose, mais légèrement développée pour établir des comparaisons plus épaisses.
| Fonctionnalité | Ce que c'est | Multithread ? | HTTPS ? | Accès DOM ? |
|---|---|---|---|---|
| Prise Web | Établit une connexion bidirectionnelle ouverte et persistante entre le navigateur et le serveur pour envoyer et recevoir des messages sur une seule connexion déclenchée par des événements. | Fonctionne sur le thread principal | Pas nécessaire | Oui |
| Travailleur Web | Permet aux scripts de s'exécuter en arrière-plan dans des threads séparés pour empêcher les scripts de se bloquer mutuellement sur le thread principal. | S'exécute sur un thread séparé | Requis | Non |
| travailleur des services | Un type de Web Worker qui crée un service d'arrière-plan qui agit comme middleware pour gérer les requêtes réseau entre le navigateur et le serveur, même dans des situations hors ligne. | S'exécute sur un thread séparé | Requis | Non |
