Web Sockets, Web Workers, Service Workers... disse er udtryk, du måske har læst eller overhørt. Måske ikke alle, men sandsynligvis mindst én af dem. Og selvom du har et godt styr på frontend-udvikling, er der en god chance for, at du skal slå op, hvad de betyder. Eller måske er du ligesom mig og blander dem fra tid til anden. Begreberne ser og lyder alle forfærdeligt ens, og det er virkelig nemt at få dem forvirrede.
Så lad os opdele dem sammen og skelne mellem Web Sockets, Web Workers og Service Workers. Ikke i den grove forstand, hvor vi laver et dybt dyk og får praktisk erfaring med hver enkelt - mere som en lille hjælper til at bogmærke næste gang I du har brug for en genopfriskning.
Hurtig reference
Vi starter med en oversigt på højt niveau for en hurtig sammenligning og kontrast.
| Feature | Hvad er det |
|---|---|
| Web Socket | Etablerer en åben og vedvarende tovejsforbindelse mellem browseren og serveren for at sende og modtage beskeder over en enkelt forbindelse udløst af hændelser. |
| Webarbejder | Tillader scripts at køre i baggrunden i separate tråde for at forhindre scripts i at blokere hinanden på hovedtråden. |
| Tjenesten Worker | En type Web Worker, der skaber en baggrundstjeneste, der fungerer mellemware til håndtering af netværksanmodninger mellem browseren og serveren, selv i offline situationer. |
Web-stik
En Web Socket er en to-vejs kommunikationsprotokol. Tænk på dette som et igangværende opkald mellem dig og din ven, der ikke ender, medmindre en af jer beslutter sig for at lægge røret på. Den eneste forskel er, at du er browseren, og din ven er serveren. Klienten sender en anmodning til serveren, og serveren svarer ved at behandle klientens anmodning og omvendt.
Kommunikationen er baseret på begivenheder. EN WebSocket objektet etableres og forbindes til en server, og meddelelser mellem serveren udløser hændelser, der sender og modtager dem.
Det betyder, at når den første forbindelse er oprettet, har vi en klient-server-kommunikation, hvor en forbindelse initieres og holdes i live, indtil enten klienten eller serveren vælger at afslutte den ved at sende en CloseEvent. Det gør Web Sockets ideelle til applikationer, der kræver kontinuerlig og direkte kommunikation mellem en klient og en server. De fleste definitioner, jeg har set, kalder chat-apps ud som et almindeligt tilfælde – du skriver en besked, sender den til serveren, udløser en hændelse, og serveren svarer med data uden at skulle pinge serveren igen og igen.
Overvej dette scenarie: Du er på vej ud, og du beslutter dig for at slå Google Maps til. Du ved sikkert allerede, hvordan Google Maps fungerer, men hvis du ikke gør det, finder den automatisk din placering, efter du har oprettet forbindelse til appen, og holder styr på den, uanset hvor du går. Den bruger datatransmission i realtid til at holde styr på din placering, så længe denne forbindelse er i live. Det er en websocket, der etablerer en vedvarende tovejssamtale mellem browseren og serveren for at holde disse data opdateret. En sportsapp med resultater i realtid kan også gøre brug af Web Sockets på denne måde.
Den store forskel mellem Web Sockets og Web Workers (og i forlængelse heraf, som vi vil se, Service Workers) er, at de har direkte adgang til DOM. Mens Web Workers (og Service Workers) kører på separate tråde, er Web Sockets en del af hovedtråden, som giver dem mulighed for at manipulere DOM.
Der er værktøjer og tjenester til at hjælpe med at etablere og vedligeholde Web Socket-forbindelser, herunder: SocketCluster, AsyncAPI, cowboy, WebSocket King, Kanalerog Gorilla WebSocket. MDN har en køreliste, der inkluderer andre tjenester.
Flere Web Sockets-oplysninger
Webarbejdere
Overvej et scenarie, hvor du skal udføre en masse komplekse beregninger, mens du på samme tid foretager ændringer i DOM. JavaScript er et enkelt-trådet program, og at køre mere end ét script kan forstyrre den brugergrænseflade, du forsøger at foretage ændringer til, samt den komplekse beregning, der udføres.
Det er her, webarbejderne kommer i spil.
Web Workers tillader scripts at køre i baggrunden i separate tråde for at forhindre scripts i at blokere hinanden på hovedtråden. Det gør dem gode til at forbedre ydeevnen af applikationer, der kræver intensive operationer, da disse operationer kan udføres i baggrunden på separate tråde uden at påvirke brugergrænsefladen fra gengivelse. Men de er ikke så gode til at få adgang til DOM, fordi i modsætning til Web Sockets kører en webarbejder uden for hovedtråden i sin egen tråd.
En Web Worker er et objekt, der udfører en scriptfil ved at bruge en Worker genstand for at udføre opgaverne. Og når vi taler om arbejdere, har de en tendens til at falde ind i en af tre typer:
- Dedikerede medarbejdere: En dedikeret medarbejder er kun inden for rækkevidde af manuskriptet, der kalder det. Det udfører stadig en typisk webarbejders opgaver, såsom dets multi-threading-scripts.
- Delte arbejdere: En delt arbejder er det modsatte af en dedikeret arbejder. Det kan tilgås af flere scripts og kan praktisk talt udføre enhver opgave, som en webmedarbejder udfører, så længe de findes i samme domæne som arbejderen.
- Servicemedarbejdere: En servicemedarbejder fungerer som en netværksproxy mellem en app, browseren og serveren, hvilket gør det muligt for scripts at køre, selv i tilfælde af, at netværket går offline. Vi kommer til dette i næste afsnit.
Flere oplysninger om Web Workers
Servicearbejdere
Der er nogle ting, vi ikke har kontrol over som udviklere, og en af disse ting er en brugers netværksforbindelse. Uanset hvilket netværk en bruger forbinder til, er det, hvad det er. Vi kan kun gøre vores bedste for at optimere vores apps, så de yder det bedste, de kan på enhver forbindelse, der tilfældigvis bliver brugt.
Servicemedarbejdere er en af de ting, vi kan gøre for gradvist at forbedre en apps ydeevne. En servicemedarbejder sidder mellem appen, browseren og serveren og giver en sikker forbindelse, der kører i baggrunden på en separat tråd, takket være - du gættede rigtigt - Web Workers. Som vi lærte i sidste afsnit, er Service Workers en af tre typer af Web Workers.
Så hvorfor skulle du nogensinde have brug for en servicemedarbejder, der sidder mellem din app og brugerens browser? Igen har vi ingen kontrol over brugerens netværksforbindelse. Sig, at forbindelsen forsvinder af en eller anden ukendt årsag. Det ville bryde kommunikationen mellem browseren og serveren og forhindre data i at blive sendt frem og tilbage. En servicemedarbejder vedligeholder forbindelsen og fungerer som en asynkron proxy, der er i stand til at opsnappe anmodninger og udføre opgaver - selv efter at netværksforbindelsen er mistet.
Dette er den vigtigste drivkraft for det, der ofte omtales som "offline-first" udvikling. Vi kan gemme aktiver i den lokale cache i stedet for netværket, give kritiske oplysninger, hvis brugeren går offline, forhåndshente ting, så de er klar, når brugeren har brug for dem, og give fallbacks som svar på netværksfejl. De er fuldstændig asynkrone, men i modsætning til Web Sockets har de ingen adgang til DOM, da de kører på deres egne tråde.
Den anden store ting at vide om Service Workers er, at de opsnapper hver enkelt anmodning og svar fra din app. Som sådan har de nogle sikkerhedsmæssige konsekvenser, især at de følger en politik med samme oprindelse. Så det betyder ikke at køre en servicearbejder fra en CDN eller tredjepartstjeneste. De kræver også en sikker HTTPS-forbindelse, hvilket betyder, at du skal bruge et SSL-certifikat, for at de kan køre.
Mere information om servicemedarbejdere
Indpakning op
Det er en forklaring på superhøjt niveau af forskellene (og lighederne) mellem Web Sockets, Web Workers og Service Workers. Igen er terminologien og begreberne ens nok til at blande den ene med den anden, men forhåbentlig giver dette dig en bedre idé om, hvordan du kan skelne dem.
Vi startede tingene med en hurtig referencetabel. Her er det samme, men lidt udvidet for at lave tykkere sammenligninger.
| Feature | Hvad er det | Flertrådet? | HTTPS? | DOM adgang? |
|---|---|---|---|---|
| Web Socket | Etablerer en åben og vedvarende tovejsforbindelse mellem browseren og serveren for at sende og modtage beskeder over en enkelt forbindelse udløst af hændelser. | Kører på hovedtråden | Ikke påkrævet | Ja |
| Webarbejder | Tillader scripts at køre i baggrunden i separate tråde for at forhindre scripts i at blokere hinanden på hovedtråden. | Kører på en separat tråd | påkrævet | Ingen |
| Tjenesten Worker | En type Web Worker, der skaber en baggrundstjeneste, der fungerer mellemware til håndtering af netværksanmodninger mellem browseren og serveren, selv i offline situationer. | Kører på en separat tråd | påkrævet | Ingen |
