Web Sockets, Web Workers, Service Workers... dit zijn termen die u misschien hebt gelezen of gehoord. Misschien niet allemaal, maar waarschijnlijk in ieder geval één. En zelfs als je front-end ontwikkeling goed onder de knie hebt, is de kans groot dat je moet opzoeken wat ze betekenen. Of misschien ben je net als ik en haal je ze af en toe door elkaar. De termen zien er allemaal vreselijk hetzelfde uit en klinken erg op elkaar en het is heel gemakkelijk om ze in de war te brengen.
Laten we ze dus samen opsplitsen en onderscheid maken tussen Web Sockets, Web Workers en Service Workers. Niet in de kern van de zaak, waar we een diepe duik doen en praktische ervaring opdoen met elk ervan - meer als een kleine helper om de volgende keer een bladwijzer te maken I je hebt een opfrisbeurt nodig.
Snelle referentie
We beginnen met een overzicht op hoog niveau voor een snelle vergelijking en contrast.
| Kenmerk | Wat het is |
|---|---|
| Websocket | Brengt een open en permanente tweerichtingsverbinding tot stand tussen de browser en de server om berichten te verzenden en ontvangen via een enkele verbinding die wordt geactiveerd door gebeurtenissen. |
| Webwerker | Hiermee kunnen scripts op de achtergrond in afzonderlijke threads worden uitgevoerd om te voorkomen dat scripts elkaar op de hoofdthread blokkeren. |
| dienst Worker | Een type webwerker dat een achtergrondservice maakt die als middleware fungeert voor het afhandelen van netwerkverzoeken tussen de browser en de server, zelfs in offline situaties. |
Web-sockets
Een Web Socket is een tweerichtingscommunicatieprotocol. Zie dit als een voortdurend gesprek tussen jou en je vriend dat niet zal eindigen tenzij een van jullie besluit op te hangen. Het enige verschil is dat jij de browser bent en je vriend de server. De client stuurt een verzoek naar de server en de server reageert door het verzoek van de client te verwerken en vice versa.
De communicatie is gebaseerd op gebeurtenissen. EEN WebSocket object tot stand wordt gebracht en verbinding maakt met een server, en berichten tussen de server activeren gebeurtenissen die ze verzenden en ontvangen.
Dit betekent dat wanneer de eerste verbinding tot stand is gebracht, we een client-servercommunicatie hebben waarbij een verbinding wordt gestart en in stand wordt gehouden totdat de client of server ervoor kiest deze te beëindigen door een CloseEvent. Dat maakt Web Sockets ideaal voor toepassingen die continue en directe communicatie tussen een client en een server vereisen. De meeste definities die ik heb gezien, noemen chat-apps als een veelvoorkomend gebruik: je typt een bericht, stuurt het naar de server, activeert een gebeurtenis en de server reageert met gegevens zonder de server steeds opnieuw te hoeven pingen.
Overweeg dit scenario:: Je bent op weg naar buiten en je besluit Google Maps in te schakelen. U weet waarschijnlijk al hoe Google Maps werkt, maar als u dat niet weet, vindt het uw locatie automatisch nadat u verbinding heeft gemaakt met de app en houdt het deze bij waar u ook bent. Het maakt gebruik van realtime gegevensoverdracht om uw locatie bij te houden zolang deze verbinding actief is. Dat is een Web Socket die een aanhoudend tweerichtingsgesprek tot stand brengt tussen de browser en de server om die gegevens up-to-date te houden. Een sport-app met realtime scores zou op deze manier ook gebruik kunnen maken van Web Sockets.
Het grote verschil tussen Web Sockets en Web Workers (en bij uitbreiding, zoals we zullen zien, Service Workers) is dat ze directe toegang hebben tot de DOM. Terwijl Web Workers (en Service Workers) op aparte threads draaien, maken Web Sockets deel uit van de hoofdthread, waardoor ze de DOM kunnen manipuleren.
Er zijn tools en services om Web Socket-verbindingen tot stand te brengen en te onderhouden, waaronder: SocketCluster, AsynchroneAPI, cowboy, WebSocket Koning, Kanalen en Gorilla WebSocket. MDN heeft een lopende lijst met andere services.
Meer informatie over Web Sockets
Webwerkers
Overweeg een scenario waarin u een heleboel complexe berekeningen moet uitvoeren terwijl u tegelijkertijd wijzigingen aanbrengt in de DOM. JavaScript is een toepassing met één thread en het uitvoeren van meer dan één script kan de gebruikersinterface die u probeert te wijzigen en de complexe berekening die wordt uitgevoerd, verstoren.
Dit is waar de Web Workers in het spel komen.
Met Web Workers kunnen scripts op de achtergrond in afzonderlijke threads worden uitgevoerd om te voorkomen dat scripts elkaar op de hoofdthread blokkeren. Dat maakt ze geweldig voor het verbeteren van de prestaties van toepassingen die intensieve bewerkingen vereisen, omdat die bewerkingen op de achtergrond op afzonderlijke threads kunnen worden uitgevoerd zonder dat de gebruikersinterface van het renderen wordt beïnvloed. Maar ze zijn niet zo goed in het benaderen van de DOM omdat, in tegenstelling tot Web Sockets, een webwerker buiten de hoofdthread in zijn eigen thread draait.
Een webwerker is een object dat een scriptbestand uitvoert met a Worker bezwaar om de taken uit te voeren. En als we het over werknemers hebben, hebben ze de neiging om in een van de volgende drie typen te vallen:
- Toegewijde werknemers: Een toegewijde werknemer is alleen binnen handbereik door het script dat hem aanroept. Het voert nog steeds de taken uit van een typische webwerker, zoals de multi-threading-scripts.
- Gedeelde werknemers: Een gedeelde werker is het tegenovergestelde van een toegewijde werker. Het is toegankelijk voor meerdere scripts en kan praktisch elke taak uitvoeren die een webwerker uitvoert, zolang deze zich in hetzelfde domein als de werknemer bevinden.
- Servicemedewerkers: Een servicemedewerker fungeert als netwerkproxy tussen een app, de browser en de server, waardoor scripts kunnen worden uitgevoerd, zelfs als het netwerk offline gaat. We komen hier in de volgende sectie op terug.
Meer informatie over Web Workers
Servicemedewerkers
Er zijn een aantal dingen waar we als ontwikkelaars geen controle over hebben, en een van die dingen is de netwerkverbinding van een gebruiker. Met welk netwerk een gebruiker verbinding maakt, het is wat het is. We kunnen alleen ons best doen om onze apps te optimaliseren, zodat ze zo goed mogelijk presteren op elke verbinding die toevallig wordt gebruikt.
Servicemedewerkers zijn een van de dingen die we kunnen doen om de prestaties van een app geleidelijk te verbeteren. Een servicemedewerker zit tussen de app, de browser en de server en biedt een veilige verbinding die op de achtergrond op een aparte thread draait, dankzij - je raadt het al - Web Workers. Zoals we in het laatste gedeelte hebben geleerd, zijn servicemedewerkers een van de drie typen webwerkers.
Dus waarom zou u ooit een servicemedewerker nodig hebben die tussen uw app en de browser van de gebruiker zit? Nogmaals, we hebben geen controle over de netwerkverbinding van de gebruiker. Stel dat de verbinding om een onbekende reden wegvalt. Dat zou de communicatie tussen de browser en de server verbreken, waardoor gegevens niet heen en weer kunnen worden doorgegeven. Een servicemedewerker onderhoudt de verbinding en fungeert als een asynchrone proxy die verzoeken kan onderscheppen en taken kan uitvoeren, zelfs nadat de netwerkverbinding is verbroken.
Dit is de belangrijkste drijfveer van wat vaak wordt aangeduid als "offline-first" ontwikkeling. We kunnen activa opslaan in de lokale cache in plaats van in het netwerk, kritieke informatie verstrekken als de gebruiker offline gaat, dingen prefetchen zodat ze klaar zijn wanneer de gebruiker ze nodig heeft, en fallbacks bieden als reactie op netwerkfouten. Ze zijn volledig asynchroon, maar in tegenstelling tot Web Sockets hebben ze geen toegang tot de DOM omdat ze op hun eigen threads draaien.
Het andere belangrijke dat u moet weten over Service Workers, is dat ze elk verzoek en elke reactie van uw app onderscheppen. Als zodanig hebben ze enkele beveiligingsimplicaties, met name dat ze een beleid van dezelfde oorsprong volgen. Dat betekent dus dat u geen servicemedewerker hoeft uit te voeren vanaf een CDN of een service van derden. Ze vereisen ook een veilige HTTPS-verbinding, wat betekent dat je een SSL-certificaat nodig hebt om ze te kunnen gebruiken.
Meer informatie over servicemedewerkers
Afsluiten
Dat is een superhoge uitleg van de verschillen (en overeenkomsten) tussen Web Sockets, Web Workers en Service Workers. Nogmaals, de terminologie en concepten zijn vergelijkbaar genoeg om de een met de ander te verwarren, maar hopelijk geeft dit je een beter idee van hoe je ze kunt onderscheiden.
We begonnen met een snelle referentietabel. Hier is hetzelfde, maar iets uitgebreider om dikkere vergelijkingen te maken.
| Kenmerk | Wat het is | Meerdradig? | HTTPS? | DOM-toegang? |
|---|---|---|---|---|
| Websocket | Brengt een open en permanente tweerichtingsverbinding tot stand tussen de browser en de server om berichten te verzenden en ontvangen via een enkele verbinding die wordt geactiveerd door gebeurtenissen. | Draait op de rode draad | Niet verplicht | Ja |
| Webwerker | Hiermee kunnen scripts op de achtergrond in afzonderlijke threads worden uitgevoerd om te voorkomen dat scripts elkaar op de hoofdthread blokkeren. | Draait op een aparte thread | Nodig | Nee |
| dienst Worker | Een type webwerker dat een achtergrondservice maakt die als middleware fungeert voor het afhandelen van netwerkverzoeken tussen de browser en de server, zelfs in offline situaties. | Draait op een aparte thread | Nodig | Nee |
