Care este diferenta intre Web Sockets, Web Workers si Service Workers

Web Sockets, Web Workers si Service Workers...termeni pe care sigur i-ai mai auzit pe undeva, poate ai auzit de unii dintre ei, dar nu chiar pe toti 3. Stiu, suna foarte similar si s-ar putea sa ii incurci intre ei.

Hai in acest articol sa vedem ce inseamna so care sunt diferentele intre ei.

Sa ne facem o idee rapida

Hai sa vedem care sunt diferentele high-level intre cele 3:

Web Sockets

Un Web Socket este un protocol de comunicare din ambele directii (two-way). Poti sa te gandesti la el ca la un apel telefonic intre tine si un prieten care se va termina doar in momentul in care unul dintre voi decide sa il inchida.
Singura diferenta intre web socket si apelul telefonic este aceea ca tu esti browserul, iar prietenul este serverul. Clientul trimite un request catre server, iar server-ul raspunde prin a procesa cererea clientului si invers.

Acest tip de comunicare este bazat pe evenimente. Un obiect de tip web socket este creat si se conecteaza la server, apoi mesajele intre server si client pot incepe sa fie trimise.
O data ce conexiunea a fost creata este tinuta in deschisa pana la trimiterea unui eveniment de tipul CloseEvent.
Web Socket-urile sunt ideale pentru aplicatii ce necesita o comunicare permantenta intre client si server. Un exemplu cat se poate de simplu pentru aceasta tehnologie este un chat, unde poti deschide o conexiune si sa o folosesti in permantenta pentru afisarea mesajelor, fara sa fie nevoie sa tot faci ajax call-uri.

Sa ne gandim ca avem urmatorul scenariu:
Trebuie sa pleci in oras si te hotarasti sa pornesti Google Maps. Probabil deja stii cum functioneaza Google Maps, dar daca nu stii am sa zic aici, iti gaseste locatia in mod automat cand deschizi aplicatia si iti memoreaza traseul pe care ai mers. Se foloseste de o comunicare in timp real pentru a iti sti in permanenta locatia, exact cum am zis mai devreme ca functioneaza un Web Socket.

Diferenta intre Web Socket si Web Worker (si implicit Service Worker) este aceea ca au access direct la DOM. In timp ce un Web Worker (si un Service Worker) ruleaza in thread-uri separate, un Web Socket face parte din threadul principal de executie si are access la DOM.

Exista tool-uri ce pot ajuta la stanilirea unei conexiunea de acest tip:

• https://socketcluster.io/
• https://www.asyncapi.com/
• https://github.com/ninenines/cowboy
• https://websocketking.com/
• https://channels.readthedocs.io/en/stable/index.html
• https://pkg.go.dev/github.com/gorilla/websocket)

Web Workers

Gandestete la urmatorul scenariu, trebuie sa faci o multime de calcule complexe si in acelasi timp sa modifici lucruri in DOM. Dupa cum bine stim, JavaScript este single threaded, iar rularea mai multor script-uri in mod simultan poate duce la conflicte de afisare in interfata.

Ei bine, aici intervin Web Workers.

Web Workers permit rularea anumitor functii in thread-uri separate pentru a preveni conflictele scripturilor ce ruleaza in thread-ul principal. Acest lucru face Web Workerii perfecti pentru a imbunatati performanta aplicatiilor ce necesita operatii complexe. Cu toate acestea, web workerii nu sunt grozavi pentru a face actiuni in DOM pentru ca, spre deosebire de Web Sockets, ruleaza in alt thread de executie.

Un Web Worker este un obiect ce executa un fisier folosind un obiectd e tip Worker.
Acesti workeri sunt impartiti in 3 categorii:

Mai multe informatii
-   Off the Main Thread (Chris Coyier)
-  The State Of Web Workers In 2021 (Chris Coyier)
-  Intro to Web Workers (Zapier)
-  Web Workers API (MDN Docs)
-  Latest browser support (Caniuse)

Service Workers

Ca si dezvoltatori, avem multe lucruri pe care trebuie sa le avem in vedere cand lucram la o aplicatie, iar unul dintre aceste lucruri este si conectivitatea la retea a utilizatorului. Pentru ca nu stim la ce retea este conectat utilizatorul si nu putem face nimic in sensul asta, putem totusi avea grija ca aplicatia noastra sa functioneze cat se poate de bine indiferent de circumstantele rularii ei.

Service Workers, sau ceva ce putem face pentru a imbunatati in mod progresiv performanta aplicatiei. Un asemenea worker sta intre aplicatie, browser si server, stabilind o conexiune sigura ce ruleaza in background intr-un thread separat ca un web worker, exact ce am aflat cateva randuri mai sus.

Pai si de ce as avea nevoie de un service worker?
Continuand discutia cu reteaua de mai sus, sa presupunem ca avem o eroare de retea, utilizatorul a ramas fara semnal de exemplu. Asta ar insemna ca aplicatia noastra nu mai functioneaza pentru ca a fost intrerupta comunicarea intre browser si server. Un service worker mentine conexiunea deschisa actionand ca un proxy async ce este capabil sa intercepteze request-urile si sa execute diferite functii.

Putem salva diverse lucruri in cache-ul local in loc de a le transfera prin retea, ceea ce ne ajuta sa afisam informatii importante cand user-ul este offline, ba chiar mai mult putem aduce lucruri in avans in caz ca user-ul ramane fara retea. Acest mod de lucru este async, dar spre deosebire de un web socket, aici nu avem access la DOM.

Chestia importanta ce trebuie retinuta despre Service Workers este ca pot intercepta fiecare request si response al aplicatiei tale, deci exista si cateva implicatii de securitate aici.
Service workerii tin cont de same-origin policy, ceea ce inseamna ca nu putem rula un service worker dintr-un CDN sau dintr-un serviciu 3rd party. De asemenea, pentru a functiona au nevoie de o conexiunea HTTPS.

Mai multe informatii
-  Add a Service Worker to Your Site (Chris Ferdinadi)
-  Service worker overview (Chrome Developers)
-  Smaller HTML Payloads with Service Workers (Philip Walton)
-  Service Worker Cookbook (Mozilla)
-  Service Worker API (MDN Docs)
-  Latest browser support (Caniuse)

Concluzii

In acest articol am povestit cat se poate de sumar ce sunt Web Sockets, Web Workers si Service Workers si am aflat care sunt diferentele intre cele 3.