Skillnaden mellan Web Sockets, Web Workers och Service Workers

Web Sockets, Web Workers, Service Workers... det här är termer som du kanske har läst eller hört. Kanske inte alla, men troligen åtminstone en av dem. Och även om du har bra koll på front-end-utveckling, finns det en god chans att du behöver slå upp vad de betyder. Eller så kanske du är som jag och blandar ihop dem då och då. Termerna ser alla ut och låter fruktansvärt lika och det är verkligen lätt att få dem förvirrade.

Så, låt oss dela upp dem tillsammans och skilja på Web Sockets, Web Workers och Service Workers. Inte i den lilla bemärkelsen där vi gör en djupdykning och får praktisk erfarenhet med var och en - mer som en liten hjälpreda att bokmärka nästa gång I du behöver en uppfräschning.

Snabbreferens

Vi börjar med en översikt på hög nivå för snabb jämförelse och kontrast.

Leverans	Vad det är
Web Socket	Etablerar en öppen och bestående tvåvägsförbindelse mellan webbläsaren och servern för att skicka och ta emot meddelanden över en enda anslutning som utlöses av händelser.
Web Arbetare	Tillåter att skript körs i bakgrunden i separata trådar för att förhindra att skript blockerar varandra i huvudtråden.
Tjänsten Arbetare	En typ av Web Worker som skapar en bakgrundstjänst som fungerar mellanprogram för att hantera nätverksförfrågningar mellan webbläsaren och servern, även i offlinesituationer.

Webbuttag

En Web Socket är ett tvåvägskommunikationsprotokoll. Se det här som ett pågående samtal mellan dig och din vän som inte tar slut om inte någon av er bestämmer sig för att lägga på. Den enda skillnaden är att du är webbläsaren och din vän är servern. Klienten skickar en begäran till servern och servern svarar genom att bearbeta klientens begäran och vice versa.

Kommunikationen bygger på händelser. A WebSocket objekt upprättas och ansluter till en server, och meddelanden mellan servern utlöser händelser som skickar och tar emot dem.

Detta innebär att när den första anslutningen görs har vi en klient-serverkommunikation där en anslutning initieras och hålls vid liv tills antingen klienten eller servern väljer att avsluta den genom att skicka en CloseEvent. Det gör Web Sockets idealiska för applikationer som kräver kontinuerlig och direkt kommunikation mellan en klient och en server. De flesta definitioner jag har sett kallar ut chattappar som ett vanligt användningsfall - du skriver ett meddelande, skickar det till servern, utlöser en händelse och servern svarar med data utan att behöva pinga servern om och om igen.

Tänk på det här scenariot: Du är på väg ut och du bestämmer dig för att slå på Google Maps. Du vet förmodligen redan hur Google Maps fungerar, men om du inte gör det hittar den din plats automatiskt efter att du anslutit till appen och håller reda på den var du än går. Den använder dataöverföring i realtid för att hålla reda på din plats så länge den här anslutningen är vid liv. Det är en webbsocket som upprättar en ihållande tvåvägskonversation mellan webbläsaren och servern för att hålla dessa data uppdaterade. En sportapp med resultat i realtid kan också använda Web Sockets på detta sätt.

Den stora skillnaden mellan Web Sockets och Web Workers (och i förlängningen som vi kommer att se, Service Workers) är att de har direkt tillgång till DOM. Medan Web Workers (och Service Workers) körs på separata trådar, är Web Sockets en del av huvudtråden som ger dem möjlighet att manipulera DOM.

Det finns verktyg och tjänster för att skapa och underhålla Web Socket-anslutningar, inklusive: SocketCluster, AsyncAPI, cowboy, WebSocket King, Kanaleroch Gorilla WebSocket. MDN har en körlista som inkluderar andra tjänster.

Mer information om Web Sockets

Webbarbetare

Tänk på ett scenario där du behöver utföra en massa komplexa beräkningar samtidigt som du gör ändringar i DOM. JavaScript är en enkeltrådad applikation och att köra mer än ett skript kan störa användargränssnittet du försöker göra ändringar i såväl som den komplexa beräkningen som utförs.

Det är här webbarbetarna kommer in i bilden.

Web Workers tillåter att skript körs i bakgrunden i separata trådar för att förhindra att skript blockerar varandra i huvudtråden. Det gör dem utmärkta för att förbättra prestandan för applikationer som kräver intensiva operationer eftersom dessa operationer kan utföras i bakgrunden på separata trådar utan att det påverkar användargränssnittet från rendering. Men de är inte så bra på att komma åt DOM eftersom, till skillnad från Web Sockets, kör en webbarbetare utanför huvudtråden i sin egen tråd.

En Web Worker är ett objekt som exekverar en skriptfil med hjälp av en Worker föremål för att utföra uppgifterna. Och när vi talar om arbetare tenderar de att falla in i en av tre typer:

• Engagerade arbetare: En engagerad arbetare är bara inom räckhåll för manuset som kallar det. Den utför fortfarande uppgifterna för en typisk webbarbetare, till exempel dess flertrådsskript.
• Delade arbetare: En delad arbetare är motsatsen till en dedikerad arbetare. Det kan nås av flera skript och kan praktiskt taget utföra alla uppgifter som en webbarbetare utför så länge de finns i samma domän som arbetaren.
• Servicearbetare: En tjänstearbetare fungerar som en nätverksproxy mellan en app, webbläsaren och servern, vilket gör att skript kan köras även i händelse av att nätverket går offline. Vi kommer att komma till detta i nästa avsnitt.

Mer information om Web Workers

Servicearbetare

Det finns vissa saker som vi inte har kontroll över som utvecklare, och en av dessa saker är en användares nätverksanslutning. Vilket nätverk en användare än ansluter till är vad det är. Vi kan bara göra vårt bästa för att optimera våra appar så att de presterar så bra de kan på alla anslutningar som råkar användas.

Service Workers är en av de saker vi kan göra för att successivt förbättra en apps prestanda. En tjänstearbetare sitter mellan appen, webbläsaren och servern och tillhandahåller en säker anslutning som körs i bakgrunden på en separat tråd, tack vare - du gissade rätt - Web Workers. Som vi lärde oss i det förra avsnittet är Service Workers en av tre typer av webbarbetare.

Så varför skulle du behöva en servicearbetare som sitter mellan din app och användarens webbläsare? Återigen, vi har ingen kontroll över användarens nätverksanslutning. Säg att anslutningen försvinner av någon okänd anledning. Det skulle bryta kommunikationen mellan webbläsaren och servern och förhindra att data skickas fram och tillbaka. En servicearbetare upprätthåller anslutningen och fungerar som en asynkron proxy som kan avlyssna förfrågningar och utföra uppgifter – även efter att nätverksanslutningen har förlorats.

Detta är den främsta drivkraften för vad som ofta kallas "offline-först" utveckling. Vi kan lagra tillgångar i den lokala cachen istället för nätverket, tillhandahålla viktig information om användaren går offline, förhämta saker så att de är redo när användaren behöver dem och ge reservdelar som svar på nätverksfel. De är helt asynkrona men till skillnad från Web Sockets har de ingen tillgång till DOM eftersom de körs på sina egna trådar.

Den andra stora saken att veta om Service Workers är att de fångar upp varje begäran och svar från din app. Som sådana har de vissa säkerhetskonsekvenser, framför allt att de följer en policy för samma ursprung. Så det betyder att man inte kan köra en tjänstearbetare från en CDN eller tredjepartstjänst. De kräver också en säker HTTPS-anslutning, vilket innebär att du behöver ett SSL-certifikat för att de ska kunna köras.

Mer information om servicearbetare

Inslagning upp

Det är en förklaring på superhög nivå av skillnaderna (och likheterna) mellan Web Sockets, Web Workers och Service Workers. Återigen, terminologin och begreppen är tillräckligt lika för att blanda ihop dem med varandra, men förhoppningsvis ger detta dig en bättre uppfattning om hur du kan skilja dem åt.

Vi började med en snabb referenstabell. Här är samma sak, men något utökat för att göra tjockare jämförelser.

Leverans	Vad det är	Flertrådad?	HTTPS?	DOM-åtkomst?
Web Socket	Etablerar en öppen och bestående tvåvägsförbindelse mellan webbläsaren och servern för att skicka och ta emot meddelanden över en enda anslutning som utlöses av händelser.	Går på huvudtråden	Krävs inte	Ja
Web Arbetare	Tillåter att skript körs i bakgrunden i separata trådar för att förhindra att skript blockerar varandra i huvudtråden.	Går på en separat tråd	Krävs	Nej
Tjänsten Arbetare	En typ av Web Worker som skapar en bakgrundstjänst som fungerar mellanprogram för att hantera nätverksförfrågningar mellan webbläsaren och servern, även i offlinesituationer.	Går på en separat tråd	Krävs	Nej