Web Socket, Web Worker, Service Workers... questi sono termini che potresti aver letto o sentito. Forse non tutti, ma probabilmente almeno uno. E anche se hai una buona padronanza dello sviluppo front-end, ci sono buone possibilità che tu debba cercare cosa significano. O forse sei come me e mescoli di tanto in tanto. I termini sembrano tutti terribilmente simili ed è davvero facile confonderli.
Quindi, analizziamoli insieme e distinguiamo Web Socket, Web Worker e Service Worker. Non nel vero senso della parola in cui facciamo un'immersione profonda e otteniamo un'esperienza pratica con ciascuno di essi, più come un piccolo aiuto da aggiungere ai segnalibri la prossima volta I hai bisogno di una rinfrescata.
Riferimento rapido
Inizieremo con una panoramica di alto livello per un rapido confronto e contrasto.
| caratteristica | Cos'è |
|---|---|
| Presa Web | Stabilisce una connessione bidirezionale aperta e persistente tra il browser e il server per inviare e ricevere messaggi su un'unica connessione attivata da eventi. |
| Operatore web | Consente l'esecuzione degli script in background in thread separati per evitare che gli script si blocchino a vicenda sul thread principale. |
| Servizio Worker | Un tipo di Web Worker che crea un servizio in background che agisce come middleware per la gestione delle richieste di rete tra il browser e il server, anche in situazioni offline. |
Web Socket
Un Web Socket è un protocollo di comunicazione bidirezionale. Pensa a questo come a una chiamata in corso tra te e il tuo amico che non finirà a meno che uno di voi non decida di riattaccare. L'unica differenza è che tu sei il browser e il tuo amico è il server. Il client invia una richiesta al server e il server risponde elaborando la richiesta del client e viceversa.
La comunicazione si basa sugli eventi. UN WebSocket l'oggetto viene stabilito e si connette a un server e i messaggi tra il server attivano eventi che li inviano e li ricevono.
Ciò significa che quando viene stabilita la connessione iniziale, abbiamo una comunicazione client-server in cui una connessione viene avviata e mantenuta attiva fino a quando il client o il server scelgono di terminarla inviando un CloseEvent. Ciò rende Web Sockets l'ideale per le applicazioni che richiedono una comunicazione continua e diretta tra un client e un server. La maggior parte delle definizioni ho visto richiamare le app di chat come un caso d'uso comune: si digita un messaggio, lo si invia al server, si attiva un evento e il server risponde con i dati senza dover eseguire il ping del server più e più volte.
Considera questo scenario: Stai per uscire e decidi di attivare Google Maps. Probabilmente sai già come funziona Google Maps, ma se non lo fai, trova automaticamente la tua posizione dopo che ti sei connesso all'app e ne tiene traccia ovunque tu vada. Utilizza la trasmissione di dati in tempo reale per tenere traccia della tua posizione finché questa connessione è attiva. Questo è un Web Socket che stabilisce una conversazione bidirezionale persistente tra il browser e il server per mantenere aggiornati i dati. Anche un'app sportiva con punteggi in tempo reale potrebbe utilizzare Web Sockets in questo modo.
La grande differenza tra Web Socket e Web Worker (e, come vedremo, Service Worker) è che hanno accesso diretto al DOM. Mentre i Web Worker (e i Service Worker) vengono eseguiti su thread separati, i Web Socket fanno parte del thread principale che offre loro la possibilità di manipolare il DOM.
Sono disponibili strumenti e servizi per stabilire e mantenere connessioni Web Socket, tra cui: Socket Cluster, API asincrona, cowboy, Re dei WebSocket, Canalie GorillaWebSocket. MDN ha un elenco in esecuzione che include altri servizi.
Ulteriori informazioni sui Web Socket
Lavoratori Web
Considera uno scenario in cui è necessario eseguire una serie di calcoli complessi mentre allo stesso tempo apportare modifiche al DOM. JavaScript è un'applicazione a thread singolo e l'esecuzione di più di uno script potrebbe interrompere l'interfaccia utente a cui si sta tentando di apportare modifiche, nonché il complesso calcolo eseguito.
È qui che entrano in gioco i Web Workers.
I Web Worker consentono l'esecuzione degli script in background in thread separati per evitare che gli script si blocchino a vicenda sul thread principale. Ciò li rende ottimi per migliorare le prestazioni delle applicazioni che richiedono operazioni intensive poiché tali operazioni possono essere eseguite in background su thread separati senza influire sull'interfaccia utente dal rendering. Ma non sono così bravi ad accedere al DOM perché, a differenza di Web Sockets, un web worker viene eseguito all'esterno del thread principale nel proprio thread.
Un Web Worker è un oggetto che esegue un file di script utilizzando a Worker opporsi allo svolgimento dei compiti. E quando si parla di lavoratori, tendono a rientrare in uno di questi tre tipi:
- Lavoratori dedicati: Un lavoratore dedicato è raggiungibile solo dallo script che lo chiama. Esegue comunque le attività di un tipico web worker, come i suoi script multi-threading.
- Lavoratori condivisi: Un lavoratore condiviso è l'opposto di un lavoratore dedicato. È accessibile da più script e può praticamente eseguire qualsiasi attività eseguita da un web worker, purché esistano nello stesso dominio del lavoratore.
- Operatori di servizio: Un addetto al servizio funge da proxy di rete tra un'app, il browser e il server, consentendo l'esecuzione degli script anche nel caso in cui la rete sia offline. Ci arriveremo nella prossima sezione.
Ulteriori informazioni sui lavoratori Web
Lavoratori del servizio
Ci sono alcune cose su cui non abbiamo il controllo come sviluppatori e una di queste cose è la connessione di rete di un utente. Qualunque sia la rete a cui un utente si connette è quello che è. Possiamo solo fare del nostro meglio per ottimizzare le nostre app in modo che funzionino al meglio su qualsiasi connessione che viene utilizzata.
I Service Worker sono una delle cose che possiamo fare per migliorare progressivamente le prestazioni di un'app. Un addetto ai servizi si trova tra l'app, il browser e il server, fornendo una connessione sicura che viene eseguita in background su un thread separato, grazie a - avete indovinato - Web Workers. Come abbiamo appreso nell'ultima sezione, i Service Worker sono uno dei tre tipi di Web Worker.
Quindi, perché mai avresti bisogno di un addetto ai servizi seduto tra la tua app e il browser dell'utente? Anche in questo caso, non abbiamo alcun controllo sulla connessione di rete dell'utente. Supponiamo che la connessione si interrompa per qualche motivo sconosciuto. Ciò interromperebbe la comunicazione tra il browser e il server, impedendo il passaggio di dati avanti e indietro. Un addetto ai servizi mantiene la connessione, agendo come un proxy asincrono in grado di intercettare le richieste ed eseguire attività, anche dopo che la connessione di rete è stata interrotta.
Questo è il driver principale di ciò che viene spesso chiamato sviluppo "offline-first".. Possiamo archiviare le risorse nella cache locale anziché nella rete, fornire informazioni critiche se l'utente va offline, precaricare le cose in modo che siano pronte quando l'utente ne ha bisogno e fornire fallback in risposta agli errori di rete. Sono completamente asincroni ma, a differenza dei Web Socket, non hanno accesso al DOM poiché vengono eseguiti sui propri thread.
L'altra cosa importante da sapere sui Service Workers è che intercettano ogni singola richiesta e risposta dalla tua app. In quanto tali, hanno alcune implicazioni sulla sicurezza, in particolare il fatto che seguono una politica della stessa origine. Ciò significa che non è possibile eseguire un lavoratore del servizio da una rete CDN o da un servizio di terze parti. Richiedono anche una connessione HTTPS sicura, il che significa che avrai bisogno di un certificato SSL per l'esecuzione.
Ulteriori informazioni sugli operatori di servizio
Concludendo
Questa è una spiegazione di altissimo livello delle differenze (e somiglianze) tra Web Socket, Web Worker e Service Worker. Ancora una volta, la terminologia e i concetti sono abbastanza simili da confondersi l'uno con l'altro, ma si spera che questo ti dia un'idea migliore di come distinguerli.
Abbiamo dato il via alle cose con una tabella di riferimento rapido. Ecco la stessa cosa, ma leggermente ampliata per tracciare confronti più spessi.
| caratteristica | Cos'è | Multithread? | HTTPS? | Accesso DOM? |
|---|---|---|---|---|
| Presa Web | Stabilisce una connessione bidirezionale aperta e persistente tra il browser e il server per inviare e ricevere messaggi su un'unica connessione attivata da eventi. | Funziona sul thread principale | Non richiesto | Sì |
| Operatore web | Consente l'esecuzione degli script in background in thread separati per evitare che gli script si blocchino a vicenda sul thread principale. | Funziona su un thread separato | Obbligatorio | Non |
| Servizio Worker | Un tipo di Web Worker che crea un servizio in background che agisce come middleware per la gestione delle richieste di rete tra il browser e il server, anche in situazioni offline. | Funziona su un thread separato | Obbligatorio | Non |
