La différence entre les prises Web, les travailleurs du Web et les travailleurs des services

Websockets, travailleurs du Web, travailleurs de services ... ces termes que vous avez peut-être rencontrés dans la lecture ou l'écoute. Peut-être pas tous, mais au moins l'un d'entre eux. Même si vous connaissez le développement frontal, il y a de fortes chances que vous ayez besoin de savoir ce qu'ils signifient. Ou vous pourriez être comme moi, les confondant parfois. Ces termes semblent très similaires et solides et sont facilement confus.

Décomposons-les ensemble pour faire la distinction entre les lignes Web, les travailleurs du Web et les travailleurs de service. Au lieu d'aller profondément dans les détails, effectuer des recherches approfondies et expérimenter chacun pour vous-même - plus comme un petit assistant afin que vous puissiez le collecter la prochaine fois que vous devrez revoir.

Référence rapide

Nous allons commencer par un aperçu avancé pour des comparaisons et des comparaisons rapides.

WebSockets

WebSocket est un protocole de communication bidirectionnel. Considérez-le comme un appel constant entre vous et un ami qui ne finira pas à moins que l'une des parties ne décide de raccrocher. La seule différence est que vous êtes le navigateur et que vos amis sont 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 des événements. Créez un objet WebSocket et connectez-vous au serveur, et les messages entre les serveurs déclenchent des événements pour les envoyer et les recevoir.

Cela signifie que lorsqu'une connexion initiale est établie, nous avons une communication client-serveur où la connexion est démarrée et reste active jusqu'à ce que le client ou le serveur choisit de le résilier en envoyant un eEVENT. Cela rend WebSockets idéal pour les applications qui nécessitent une communication continue et directe entre les clients et les serveurs. Beaucoup des définitions que j'ai vues répertorier les applications de chat comme cas d'utilisation courants - vous tapez un message, l'envoyez au serveur, déclenchez un événement, le serveur répond avec des données sans pinging à plusieurs reprises sur le serveur.

Considérez le scénario suivant: Vous êtes en voie de sortie et décidez d'ouvrir Google Maps. Vous savez peut-être déjà comment Google Maps fonctionne, mais si vous ne le faites pas, il trouvera automatiquement votre emplacement une fois que vous serez connecté à l'application et le suivez où que vous alliez. Il utilise le transfert de données en temps réel pour suivre votre emplacement tant que cette connexion est active. Il s'agit d'un WebSocket qui établit une conversation bidirectionnelle persistante entre le navigateur et le serveur pour garder les données à jour. Les applications sportives avec des scores en temps réel peuvent également utiliser des lignes Web de cette manière.

La plus grande différence entre WebSockets et les travailleurs du Web (et les travailleurs de service que nous verrons plus tard) est qu'ils ont un accès direct au DOM. Alors que les travailleurs du Web (et les travailleurs de service) s'exécutent sur des threads séparés, WebSockets fait partie du thread principal, ce qui leur permet de faire fonctionner le DOM.

Il existe des outils et des services qui peuvent aider à établir et à maintenir des connexions WebSocket, notamment: SocketCluster, Asyncapi, Cowboy, WebSocket King, Channels et Gorilla Websocket. MDN a une liste d'exécution contenant d'autres services.

Plus d'informations Websockets

• Présentation de WebSockets - Apporter des sockets sur le Web (web.dev)
• penser à l'utilisation de la puissance et aux sites Web (Chris Coyier)
• L'API WebSocket (Docs MDN)
• Dernier support du navigateur (caniuse)

WEB WEBLESS

Considérez une situation où vous devez effectuer beaucoup de calculs complexes tout en modifiant le DOM. JavaScript est une application unique qui exécute plusieurs scripts et peut détruire l'interface utilisateur que vous essayez de modifier et les calculs complexes que vous effectuez.

C'est là que les travailleurs du Web entrent en jeu.

Les travailleurs Web permet aux scripts d'exécuter des threads séparés en arrière-plan pour empêcher les scripts de se bloquer sur le thread principal. Cela les rend idéaux pour améliorer les performances des applications qui nécessitent beaucoup d'opérations, car ces opérations peuvent être effectuées sur des threads séparés en arrière-plan sans affecter le rendu de l'interface utilisateur. Mais ils ne sont pas très bons pour accéder à DOMS, car contrairement à WebSockets, les travailleurs Web s'exécutent en dehors du fil principal de son propre fil.

Le travailleur Web est un objet qui exécute des fichiers de script pour effectuer des tâches en utilisant des objets de travail. Lorsque nous parlons de travailleurs, ils ont tendance à tomber dans l'un des trois types:

• Travailleur spécial: Le travailleur spécial ne peut être accessible que par le script qui l'appelle. Il effectue toujours des tâches de travailleur Web typique, comme ses scripts multithread.
• Partager un travailleur: Le travailleur partagé est l'opposé d'un travailleur dévoué. Il est accessible par plusieurs scripts et peut effectivement effectuer toutes les tâches effectuées par le travailleur Web tant qu'elles existent dans le même domaine que le travailleur.
• Travailleurs de services: Le travailleur de service agit comme un proxy de réseau entre les applications, les navigateurs et les serveurs, permettant aux scripts d'exécuter même lorsque le réseau est hors ligne. Nous le couvrirons dans la section suivante.

Plus d'informations sur les travailleurs du Web

• "hors du thread principal" (Chris Coyier)
• L'état des travailleurs du Web en 2021 (Chris Coyier)
• Intro aux travailleurs du Web (Zapier)
• API des travailleurs Web (docs MDN)
• Dernier support du navigateur (caniuse)

Les travailleurs du service

Il y a certaines choses que nous, en tant que développeurs, ne pouvons pas contrôler, et l'une d'entre elles est la connexion réseau de l'utilisateur. Tout réseau auquel l'utilisateur se connecte est lui-même. Nous ne pouvons faire de notre mieux que pour optimiser nos applications afin qu'ils obtiennent les meilleures performances sur toute connexion qui se trouve être utilisée.

Les travailleurs du service sont l'une de certaines choses que nous pouvons faire pour améliorer progressivement les performances de notre application. Les travailleurs de service sont situés entre l'application, le navigateur et le serveur, fournissant des connexions filetées sécurisées et séparées à exécuter en arrière-plan, grâce à - vous l'avez deviné - les travailleurs Web. Comme nous l'avons appris dans la section précédente, les travailleurs du service sont l'un des trois types de travailleurs du Web.

Alors pourquoi avez-vous besoin d'un employé de service situé entre votre application et le navigateur de l'utilisateur? De même, nous ne pouvons pas contrôler la connexion réseau de l'utilisateur. Supposons que la connexion soit interrompue pour une raison inconnue. Cela interrompra la communication entre le navigateur et le serveur, empêchant les données d'être transmises. Le travailleur de service reste connecté et agit comme un proxy asynchrone qui intercepte les demandes et effectue des tâches, même après la perte d'une connexion réseau.

Il s'agit de la principale force motrice de ce qui est communément appelé développement "hors ligne". Nous pouvons stocker des actifs dans un cache local au lieu du réseau, fournir des informations essentielles si l'utilisateur est hors ligne, prédéfinir le contenu afin que l'utilisateur puisse utiliser en cas de besoin et fournir un repli aux erreurs de réseau. Ils sont complètement asynchrones, mais contrairement à WebSockets, ils ne peuvent pas accéder au DOM car ils fonctionnent sur leurs propres fils.

Une autre chose importante à propos des travailleurs du service est qu'ils interceptent chaque demande et réponse de votre application. Par conséquent, ils ont des risques de sécurité et, plus particulièrement, ils suivent une stratégie homologue. Par conséquent, cela signifie que le travailleur des services ne peut pas être exécuté à partir d'un CDN ou d'un service tiers. Ils ont également besoin d'une connexion HTTPS sécurisée, ce qui signifie que vous avez besoin d'un certificat SSL pour les exécuter.

Plus d'informations sur les travailleurs de service

• Ajouter un employé de service à votre site (Chris Ferdinadi)
• Présentation des travailleurs du service (développeurs de Chrome)
• Colondées utiles HTML plus petites avec travailleurs de service (Philip Walton)
• SERVICE WEURK Book (Mozilla)
• API des travailleurs de service (docs MDN)
• Dernier support du navigateur (caniuse)

Résumé

Il s'agit d'une explication super avancée des différences (et des similitudes) entre les lignes Web, les travailleurs du Web et les travailleurs de services. Encore une fois, les termes et les concepts sont suffisamment similaires pour que l'un puisse être confondu avec l'autre, mais j'espère que cela vous donnera une meilleure compréhension de la façon de les différencier.

Nous commençons par un tableau de référence rapide. C'est le même, mais légèrement élargi pour une comparaison plus détaillée. (Le formulaire doit être inséré ici, et le contenu du formulaire doit être réécrit en fonction du contenu du formulaire d'origine pour maintenir l'intention d'origine)

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!