Web Sockets, Web Workers, Service Workers… das sind Begriffe, die Sie vielleicht schon gelesen oder gehört haben. Vielleicht nicht alle, aber wahrscheinlich mindestens einen davon. Und selbst wenn Sie die Frontend-Entwicklung gut beherrschen, müssen Sie wahrscheinlich nachschlagen, was sie bedeuten. Oder vielleicht sind Sie wie ich und verwechseln sie von Zeit zu Zeit. Die Begriffe sehen und klingen alle sehr ähnlich und es ist wirklich einfach, sie zu verwechseln.
Lassen Sie uns sie also gemeinsam aufschlüsseln und Web Sockets, Web Workers und Service Workers unterscheiden. Nicht im Detail, wo wir tief eintauchen und praktische Erfahrungen mit jedem einzelnen sammeln – eher wie eine kleine Hilfe zum Lesezeichen für das nächste Mal, wenn ich Sie eine Auffrischung brauchen.
Schnellreferenz
Wir beginnen mit einem allgemeinen Überblick für einen schnellen Vergleich und Kontrast.
| Merkmal | Was es ist |
|---|---|
| Web Socket | Stellt eine offene und persistente bidirektionale Verbindung zwischen dem Browser und dem Server her, um Nachrichten über eine einzige Verbindung ereignisgesteuert zu senden und zu empfangen. |
| Web Worker | Ermöglicht die Ausführung von Skripten im Hintergrund in separaten Threads, um zu verhindern, dass Skripte sich gegenseitig im Hauptthread blockieren. |
| Service Worker | Eine Art von Web Worker, die einen Hintergrunddienst erstellt, der als Middleware für die Verarbeitung von Netzwerkanfragen zwischen Browser und Server fungiert, auch in Offline-Situationen. |
Web Sockets
Ein Web Socket ist ein bidirektionales Kommunikationsprotokoll. Stellen Sie sich das wie ein laufendes Gespräch zwischen Ihnen und Ihrem Freund vor, das nicht endet, es sei denn, einer von Ihnen beschließt, aufzulegen. Der einzige Unterschied ist, dass Sie der Browser und Ihr Freund der Server sind. 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-Objekt wird erstellt und verbindet sich mit einem Server, und Nachrichten zwischen dem Server lösen Ereignisse aus, die sie senden und empfangen.
Das bedeutet, dass nach der anfänglichen Verbindung eine Client-Server-Kommunikation stattfindet, bei der eine Verbindung aufgebaut und aufrechterhalten wird, bis entweder der Client oder der Server sie durch Senden eines CloseEvent beendet. 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, nennen Chat-Apps als häufigen Anwendungsfall – Sie tippen eine Nachricht, 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.
Stellen Sie sich dieses Szenario vor: Sie sind unterwegs und entscheiden sich, Google Maps zu öffnen. Sie wissen wahrscheinlich bereits, wie Google Maps funktioniert, aber falls nicht: Es findet automatisch Ihren Standort, 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 ein persistentes bidirektionales Gespräch zwischen dem Browser und dem Server herstellt, um diese Daten auf dem neuesten Stand zu halten. Eine Sport-App mit Echtzeit-Ergebnissen könnte Web Sockets auf diese Weise ebenfalls nutzen.
Der große Unterschied zwischen Web Sockets und Web Workers (und damit auch Service Workers, wie wir sehen werden) ist, dass sie direkten Zugriff auf das DOM haben. Während Web Workers (und Service Workers) in separaten Threads laufen, sind Web Sockets Teil des Hauptthreads, was ihnen die Möglichkeit gibt, das DOM zu manipulieren.
Es gibt Tools und Dienste, die bei der Einrichtung und Wartung von Web Socket-Verbindungen helfen, darunter: SocketCluster, AsyncAPI, cowboy, WebSocket King, Channels und Gorilla WebSocket. MDN hat eine laufende Liste, die weitere Dienste enthält.
Weitere Informationen zu Web Sockets
- Einführung in WebSockets – Sockets im Web (web.dev)
- Über den Stromverbrauch von Websites nachdenken (Chris Coyier)
- Die WebSocket API (MDN Docs)
- Aktuelle Browserunterstützung (Caniuse)
Web Workers
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-Threaded-Anwendung, und die Ausführung von mehr als einem Skript könnte die Benutzeroberfläche, die Sie zu ändern versuchen, sowie die durchgeführte komplexe Berechnung stören.
Hier kommen die Web Worker ins Spiel.
Web Worker ermöglichen die Ausführung von Skripten im Hintergrund in separaten Threads, um zu verhindern, dass sich Skripte gegenseitig im Hauptthread blockieren. Das macht sie großartig für die Verbesserung der Leistung von Anwendungen, die intensive Operationen erfordern, da diese Operationen im Hintergrund auf separaten Threads ausgeführt werden können, ohne die Darstellung der Benutzeroberfläche zu beeinträchtigen. Aber sie sind nicht so gut darin, auf das DOM zuzugreifen, denn im Gegensatz zu Web Sockets läuft ein Web Worker außerhalb des Hauptthreads in seinem eigenen Thread.
Ein Web Worker ist ein Objekt, das eine Skriptdatei ausführt, indem es ein Worker-Objekt verwendet, um die Aufgaben auszuführen. Und wenn wir von Workern sprechen, fallen sie tendenziell in eine von drei Kategorien
- Dedizierte Worker: Ein dedizierter Worker ist nur für das Skript erreichbar, das ihn aufruft. Er führt immer noch die Aufgaben eines typischen Web Workers aus, wie z. B. seine Multi-Threading-Skripte.
- Shared Workers: Ein Shared Worker ist das Gegenteil eines dedizierten Workers. Er kann von mehreren Skripten abgerufen werden und praktisch jede Aufgabe ausführen, die ein Web Worker ausführt, solange sie sich in derselben Domäne wie der Worker befinden.
- Service Workers: Ein Service Worker fungiert als Netzwerk-Proxy zwischen einer App, dem Browser und dem Server und ermöglicht die Ausführung von Skripten auch dann, wenn das Netzwerk offline geht. Darauf werden wir im nächsten Abschnitt eingehen.
Weitere Informationen zu Web Workers
- „Off the Main Thread“ (Chris Coyier)
- Der Stand von Web Workers im Jahr 2021 (Chris Coyier)
- Einführung in Web Workers (Zapier)
- Web Workers API (MDN Docs)
- Aktuelle Browserunterstützung (Caniuse)
Service Workers
Es gibt einige Dinge, auf die wir als Entwickler keinen Einfluss haben, und eines davon ist die Netzwerkverbindung eines Benutzers. Welches Netzwerk ein Benutzer auch wählt, das ist es eben. Wir können nur unser Bestes tun, um unsere Apps zu optimieren, damit sie auf jeder Verbindung die bestmögliche Leistung erbringen.
Service Worker sind eines der Dinge, mit denen wir die Leistung einer App progressiv verbessern können. Ein Service Worker sitzt zwischen der App, dem Browser und dem Server und bietet eine sichere Verbindung, die dank – Sie haben es erraten – Web Workern im Hintergrund auf einem separaten Thread läuft. Wie wir im letzten Abschnitt gelernt haben, sind Service Worker eine von drei Arten von Web Workern.
Warum also einen Service Worker zwischen Ihrer App und dem Browser des Benutzers haben? Auch hier haben wir keine Kontrolle über die Netzwerkverbindung des Benutzers. Angenommen, die Verbindung bricht aus unbekannten Gründen ab. Das würde die Kommunikation zwischen dem Browser und dem Server unterbrechen und verhindern, dass Daten hin und her übertragen werden. Ein Service Worker hält die Verbindung aufrecht und fungiert als asynchroner Proxy, der Anfragen abfangen und Aufgaben ausführen kann – auch nach dem Verlust der Netzwerkverbindung.
Dies ist der Haupttreiber für das, was oft als „Offline-First“-Entwicklung bezeichnet wird. Wir können Assets im lokalen Cache statt im Netzwerk speichern, kritische 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, aber im Gegensatz zu Web Sockets haben sie keinen Zugriff auf das DOM, da sie auf eigenen Threads laufen.
Das andere Wichtige, was man über Service Worker wissen muss, ist, dass sie jede einzelne Anfrage und Antwort Ihrer App abfangen. Daher haben sie einige sicherheitsrelevante Auswirkungen, insbesondere dass sie einer Same-Origin-Policy folgen. Das bedeutet, dass ein Service Worker nicht von einem CDN oder einem Drittanbieterdienst ausgeführt werden kann. 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 Service Workern
- Einen Service Worker zu Ihrer Website hinzufügen (Chris Ferdinandi)
- Übersicht über Service Worker (Chrome Developers)
- Kleinere HTML-Payloads mit Service Workern (Philip Walton)
- Service Worker Kochbuch (Mozilla)
- Service Worker API (MDN Docs)
- Aktuelle Browserunterstützung (Caniuse)
Zusammenfassung
Das ist eine sehr oberflächliche Erklärung der Unterschiede (und Gemeinsamkeiten) zwischen Web Sockets, Web Workers und Service Workers. Noch einmal, die Terminologie und die Konzepte sind ähnlich genug, um sie miteinander zu verwechseln, aber hoffentlich gibt Ihnen dies eine bessere Vorstellung davon, wie man sie unterscheidet.
Wir haben mit einer schnellen Referenztabelle begonnen. Hier ist dieselbe, aber leicht erweitert, um deutlichere Vergleiche zu ziehen.
| Merkmal | Was es ist | Multithreaded? | HTTPS? | DOM-Zugriff? |
|---|---|---|---|---|
| Web Socket | Stellt eine offene und persistente bidirektionale Verbindung zwischen dem Browser und dem Server her, um Nachrichten über eine einzige Verbindung ereignisgesteuert zu senden und zu empfangen. | Läuft im Hauptthread | Nicht erforderlich | Ja |
| Web Worker | Ermöglicht die Ausführung von Skripten im Hintergrund in separaten Threads, um zu verhindern, dass Skripte sich gegenseitig im Hauptthread blockieren. | Läuft in einem separaten Thread | Erforderlich | Nein |
| Service Worker | Eine Art von Web Worker, die einen Hintergrunddienst erstellt, der als Middleware für die Verarbeitung von Netzwerkanfragen zwischen Browser und Server fungiert, auch in Offline-Situationen. | Läuft in einem separaten Thread | Erforderlich | Nein |
Toller Artikel Aisha, das war informativ
Danke für das Update
Ein wichtiger architektonischer Unterschied zwischen Service Worker und anderen Workern ist, dass die Webseite/der Tab die Lebensdauer und Aktivierung von regulären Workern steuert, während Service Worker vom Browser gestartet/gestoppt werden und nur garantiert für die Dauer von Event-Handlern am Leben gehalten werden.
Shared Worker ist dem Service Worker am ähnlichsten, da er zwischen Tabs desselben Ursprungs geteilt wird. Die Lebensdauer von Shared Worker wird jedoch von der App gesteuert – so kann er so lange bestehen bleiben, wie er nützlich ist, und zustandsbehaftet sein. Die Lebensdauer von Service Worker wird vom Browser gesteuert und oft bei Inaktivität beendet. Service Worker können viele Male pro Sekunde gestartet/gestoppt werden (wenn keine Event-Handler laufen).
Leider ist Shared Worker unter Chrome Android noch nicht implementiert, aber er ist in allen anderen wichtigen Browsern implementiert.
Dieses Issue verfolgt Shared Worker auf Chrome Android – hoffentlich bald verfügbar! Und es gibt auch einige Diskussionen über die Kompromisse zwischen Service Worker und Shared Worker.