I Service Workers consentono di migliorare le prestazioni dell’accesso alla rete delle applicazioni web.
Il suo posizionamento è tra l’app, il browser ed il server, impostando una connessione sicura eseguita in background e soprattutto su un thread separato.
I service worker sono un tipo particolare di web worker, come ho già descritto nel post precedente.
In tutte le sessioni web che vengono generate a partire dal browser, non abbiamo un controllo sulla connessione di rete (e delle sue caratteristiche).
Se per qualche motivo la connessione si dovesse interrompere la comunicazione tra browser e server, un service worker consente di mantenere attiva la connessione come se fossimo in presenza di un proxy (disconnesso) in grado di interecettare le richieste e gestirle internamente anche nel caso in cui la connessione non sia più presente.
Questo tipo di approccio è molto utile quando si devono sviluppare applicazioni off-line, ovvero applicazioni in cui possiamo memroizzare risorse all’interno della cache locale (ed accedervi come se fossimo in presenza della rete), fornire informazioni critiche all’utente, aggiungere access token alle richieste (e memorizzarli).
Si tratta di oggetti compleamente asincroni, ma che non possono in alcun modo interagire con il DOM dell’applicazione.
E’ da notare che intercettano qualsiasi richiesta che viene generata dal browser e che viene inviata al server.
Non è possibile eseguire un service worker da una CDN o da un servizio di terze parti, perchè gestiscono la same-origin policy, esattamente come i web workers.
Inoltre, richiedono per il loro funzionamento, una connessione di rete HTTPS sicura, e quindi necessitano di un certificato SSL sicuro.