Web Sockets, Web Worker, Service Worker … das sind Begriffe, die Sie vielleicht gelesen oder gehört haben. Vielleicht nicht alle, aber wahrscheinlich zumindest einer. Und selbst wenn Sie die Front-End-Entwicklung gut beherrschen, besteht eine gute Chance, dass Sie nachschlagen müssen, was sie bedeuten. Oder vielleicht bist du wie ich und verwechselst sie von Zeit zu Zeit. Die Begriffe sehen und klingen alle schrecklich ähnlich und es ist wirklich leicht, sie zu verwechseln.
Lassen Sie uns sie also zusammen aufschlüsseln und Web Sockets, Web Worker und Service Worker unterscheiden. Nicht im eigentlichen Sinne, wo wir tief eintauchen und praktische Erfahrungen mit jedem sammeln – eher wie ein kleiner Helfer, um das nächste Mal ein Lesezeichen zu setzen I Sie brauchen eine Auffrischung.
Kurzübersicht
Wir beginnen mit einer allgemeinen Übersicht für einen schnellen Vergleich und Kontrast.
| Merkmal | Was es ist |
|---|---|
| Web-Socket | Stellt eine offene und dauerhafte bidirektionale Verbindung zwischen dem Browser und dem Server her, um Nachrichten über eine einzelne Verbindung zu senden und zu empfangen, die durch Ereignisse ausgelöst wird. |
| Web-Worker | Ermöglicht die Ausführung von Skripts im Hintergrund in separaten Threads, um zu verhindern, dass sich Skripts im Haupt-Thread gegenseitig blockieren. |
| Servicemitarbeiter | Eine Art von Web Worker, der einen Hintergrunddienst erstellt, der als Middleware fungiert, um Netzwerkanforderungen zwischen dem Browser und dem Server zu verarbeiten, sogar in Offline-Situationen. |
Web-Sockets
Ein Web Socket ist ein bidirektionales Kommunikationsprotokoll. Stellen Sie sich das wie einen laufenden Anruf zwischen Ihnen und Ihrem Freund vor, der nicht beendet wird, es sei denn, einer von Ihnen beschließt, aufzulegen. Der einzige Unterschied besteht darin, dass Sie der Browser sind und Ihr Freund der Server. Der Client sendet eine Anfrage an den Server und der Server antwortet, indem er die Anfrage des Clients verarbeitet und umgekehrt.
Die Kommunikation basiert auf Ereignissen. EIN WebSocket Das Objekt wird eingerichtet und stellt eine Verbindung zu einem Server her, und Nachrichten zwischen den Servern lösen Ereignisse aus, die sie senden und empfangen.
Das bedeutet, dass wir beim Herstellen der ersten Verbindung eine Client-Server-Kommunikation haben, bei der eine Verbindung initiiert und aufrechterhalten wird, bis entweder der Client oder der Server entscheidet, sie durch Senden von a zu beenden CloseEvent. Das macht Web Sockets ideal für Anwendungen, die eine kontinuierliche und direkte Kommunikation zwischen einem Client und einem Server erfordern. Die meisten Definitionen, die ich gesehen habe, bezeichnen Chat-Apps als häufigen Anwendungsfall – Sie geben eine Nachricht ein, senden sie an den Server, lösen ein Ereignis aus und der Server antwortet mit Daten, ohne den Server immer wieder anpingen zu müssen.
Betrachten Sie dieses Szenario: Sie sind auf dem Weg nach draußen und beschließen, Google Maps einzuschalten. Sie wissen wahrscheinlich bereits, wie Google Maps funktioniert, aber wenn Sie dies nicht tun, findet es Ihren Standort automatisch, nachdem Sie sich mit der App verbunden haben, und verfolgt ihn, wohin Sie auch gehen. Es verwendet Echtzeit-Datenübertragung, um Ihren Standort zu verfolgen, solange diese Verbindung besteht. Das ist ein Web-Socket, der eine dauerhafte wechselseitige Kommunikation zwischen Browser und Server herstellt, um diese Daten auf dem neuesten Stand zu halten. Eine Sport-App mit Echtzeitergebnissen könnte auf diese Weise auch Web Sockets verwenden.
Der große Unterschied zwischen Web Sockets und Web Workern (und im weiteren Sinne, wie wir sehen werden, Service Workern) besteht darin, dass sie direkten Zugriff auf das DOM haben. Während Web Worker (und Service Worker) in separaten Threads ausgeführt werden, sind Web Sockets Teil des Hauptthreads, der ihnen die Möglichkeit gibt, das DOM zu manipulieren.
Es gibt Tools und Dienste, die dabei helfen, Web-Socket-Verbindungen herzustellen und aufrechtzuerhalten, einschließlich: SocketCluster, AsyncAPI, Cowboy, WebSocket-König, Kanäle und Gorilla-WebSocket. MDN hat eine laufende Liste, die andere Dienste enthält.
Weitere Informationen zu Web Sockets
Web Worker
Stellen Sie sich ein Szenario vor, in dem Sie eine Reihe komplexer Berechnungen durchführen und gleichzeitig Änderungen am DOM vornehmen müssen. JavaScript ist eine Single-Thread-Anwendung, und das Ausführen von mehr als einem Skript kann die Benutzeroberfläche, an der Sie Änderungen vornehmen möchten, sowie die komplexe Berechnung, die durchgeführt wird, stören.
Hier kommen die Web Worker ins Spiel.
Web Worker ermöglichen die Ausführung von Skripts im Hintergrund in separaten Threads, um zu verhindern, dass sich Skripts im Haupt-Thread gegenseitig blockieren. Dadurch eignen sie sich hervorragend zur Verbesserung der Leistung von Anwendungen, die intensive Vorgänge erfordern, da diese Vorgänge im Hintergrund in separaten Threads ausgeführt werden können, ohne dass die Benutzeroberfläche durch das Rendern beeinträchtigt wird. Aber sie sind nicht so gut darin, auf das DOM zuzugreifen, weil ein Web-Worker im Gegensatz zu Web Sockets außerhalb des Haupt-Threads in seinem eigenen Thread läuft.
Ein Web Worker ist ein Objekt, das eine Skriptdatei mithilfe von a ausführt Worker widersprechen, die Aufgaben auszuführen. Und wenn wir über Arbeitnehmer sprechen, fallen sie in der Regel in einen von drei Typen:
- Engagierte Mitarbeiter: Ein dedizierter Worker ist nur durch das Skript erreichbar, das ihn aufruft. Es führt immer noch die Aufgaben eines typischen Web-Workers aus, wie beispielsweise seine Multi-Threading-Skripte.
- Geteilte Arbeiter: Ein Shared Worker ist das Gegenteil eines Dedicated Workers. Es kann von mehreren Skripten aufgerufen werden und kann praktisch jede Aufgabe ausführen, die ein Webworker ausführt, solange sie sich in derselben Domäne wie der Worker befinden.
- Servicemitarbeiter: Ein Service Worker fungiert als Netzwerk-Proxy zwischen einer App, dem Browser und dem Server, sodass Skripts auch dann ausgeführt werden können, wenn das Netzwerk offline geht. Dazu kommen wir im nächsten Abschnitt.
Weitere Informationen zu Web Workers
Servicemitarbeiter
Es gibt einige Dinge, über die wir als Entwickler keine Kontrolle haben, und eines dieser Dinge ist die Netzwerkverbindung eines Benutzers. Das Netzwerk, mit dem sich ein Benutzer verbindet, ist das, was es ist. Wir können nur unser Bestes tun, um unsere Apps so zu optimieren, dass sie bei jeder verwendeten Verbindung die bestmögliche Leistung erbringen.
Service Worker sind eines der Dinge, die wir tun können, um die Leistung einer App schrittweise zu verbessern. Ein Servicemitarbeiter sitzt zwischen der App, dem Browser und dem Server und stellt eine sichere Verbindung bereit, die im Hintergrund in einem separaten Thread läuft, dank – Sie haben es erraten – Web Workers. Wie wir im letzten Abschnitt gelernt haben, sind Service Worker eine von drei Arten von Web Workern.
Warum brauchen Sie also jemals einen Servicemitarbeiter, der zwischen Ihrer App und dem Browser des Benutzers sitzt? Auch hier haben wir keine Kontrolle über die Netzwerkverbindung des Benutzers. Angenommen, die Verbindung bricht aus einem unbekannten Grund zusammen. Das würde die Kommunikation zwischen dem Browser und dem Server unterbrechen und verhindern, dass Daten hin und her übertragen werden. Ein Service-Mitarbeiter hält die Verbindung aufrecht und fungiert als asynchroner Proxy, der Anfragen abfangen und Aufgaben ausführen kann – selbst nachdem die Netzwerkverbindung unterbrochen wurde.
Dies ist der Haupttreiber dessen, was oft als bezeichnet wird „Offline-First“-Entwicklung. Wir können Assets im lokalen Cache statt im Netzwerk speichern, wichtige Informationen bereitstellen, wenn der Benutzer offline geht, Dinge vorab abrufen, damit sie bereit sind, wenn der Benutzer sie benötigt, und Fallbacks als Reaktion auf Netzwerkfehler bereitstellen. Sie sind vollständig asynchron, haben aber im Gegensatz zu Web Sockets keinen Zugriff auf das DOM, da sie in ihren eigenen Threads ausgeführt werden.
Die andere wichtige Sache, die Sie über Service Worker wissen sollten, ist, dass sie jede einzelne Anfrage und Antwort von Ihrer App abfangen. Als solche haben sie einige Auswirkungen auf die Sicherheit, vor allem, dass sie einer Same-Origin-Richtlinie folgen. Das bedeutet also, dass kein Service Worker von einem CDN oder einem Drittanbieterdienst ausgeführt werden muss. Sie erfordern auch eine sichere HTTPS-Verbindung, was bedeutet, dass Sie ein SSL-Zertifikat benötigen, damit sie ausgeführt werden können.
Weitere Informationen zu Servicemitarbeitern
Wrapping up
Das ist eine super allgemeine Erklärung der Unterschiede (und Ähnlichkeiten) zwischen Web Sockets, Web Workern und Service Workern. Auch hier sind die Terminologie und Konzepte ähnlich genug, um sie miteinander zu verwechseln, aber hoffentlich gibt Ihnen dies eine bessere Vorstellung davon, wie man sie voneinander unterscheidet.
Wir begannen mit einer Schnellreferenztabelle. Hier ist das Gleiche, aber etwas erweitert, um dickere Vergleiche zu ziehen.
| Merkmal | Was es ist | Multithreading? | HTTPS? | DOM-Zugriff? |
|---|---|---|---|---|
| Web-Socket | Stellt eine offene und dauerhafte bidirektionale Verbindung zwischen dem Browser und dem Server her, um Nachrichten über eine einzelne Verbindung zu senden und zu empfangen, die durch Ereignisse ausgelöst wird. | Läuft im Hauptthread | Nicht erforderlich | Ja |
| Web-Worker | Ermöglicht die Ausführung von Skripts im Hintergrund in separaten Threads, um zu verhindern, dass sich Skripts im Haupt-Thread gegenseitig blockieren. | Läuft in einem separaten Thread | Erforderlich | Nein |
| Servicemitarbeiter | Eine Art von Web Worker, der einen Hintergrunddienst erstellt, der als Middleware fungiert, um Netzwerkanforderungen zwischen dem Browser und dem Server zu verarbeiten, sogar in Offline-Situationen. | Läuft in einem separaten Thread | Erforderlich | Nein |
