Service worker e API Cache Storage

Jeff Posnick

Sei in difficoltà per ottenere l'affidabilità della rete. La cache HTTP del browser è la prima linea di difesa ma, come hai imparato, è davvero efficace solo quando carichi URL con versione che hai visitato in precedenza. Da sola, la cache HTTP non è sufficiente.

Fortunatamente, sono disponibili due strumenti più recenti per aiutarti a cambiare le sorti del gioco: i service worker e l'API Cache Storage. Poiché vengono utilizzati spesso insieme, vale la pena conoscerli contemporaneamente.

Service worker

Un service worker è integrato nel browser e controllato da una porzione di codice JavaScript aggiuntivo che sei responsabile della creazione. Il deployment viene eseguito insieme agli altri file che compongono la tua applicazione web.

Un service worker ha alcuni poteri speciali. Tra gli altri compiti, attende pazientemente che la tua applicazione web faccia una richiesta in uscita, quindi entra in azione intercettandola. L'operazione che il service worker fa con la richiesta intercettata spetta a te.

Per alcune richieste, la linea d'azione migliore potrebbe essere consentire alla richiesta di proseguire sulla rete, come accadrebbe se non ci fosse alcun service worker.

Per altre richieste, tuttavia, puoi sfruttare una soluzione più flessibile rispetto alla cache HTTP del browser e restituire una risposta rapida in modo affidabile senza doverti preoccupare della rete. Ciò comporta l'uso dell'altra parte del puzzle: l'API Cache Storage.

L'API Cache Storage

L'API Cache Storage apre una nuova gamma di possibilità, dando agli sviluppatori il controllo completo sui contenuti della cache. Anziché affidarsi a una combinazione di intestazioni HTTP e heuristics integrata del browser, l'API Cache Storage espone un approccio alla memorizzazione nella cache basato su codice. L'API Cache Storage è particolarmente utile quando viene richiamata dal codice JavaScript del service worker.

Aspetta... C'è un'altra cache a cui pensare ora?

Probabilmente ti starai chiedendo come "Devo ancora configurare le mie intestazioni HTTP?" e "Che cosa posso fare con questa nuova cache che non è stato possibile con la cache HTTP?" Non preoccuparti, queste sono reazioni naturali.

Ti consigliamo comunque di configurare le intestazioni Cache-Control sul tuo server web, anche quando sai di utilizzare l'API Cache Storage. Generalmente, puoi impostare Cache-Control: no-cache per gli URL senza versione e/o Cache-Control: max-age=31536000 per gli URL che contengono informazioni sul controllo delle versioni, come gli hash.

Quando compili la cache dell'API Cache Storage, il browser per impostazione predefinita controlla le voci esistenti nella cache HTTP e le utilizza, se trovate. Se aggiungi URL con il controllo delle versioni alla cache dell'API Cache Storage, il browser evita un'ulteriore richiesta di rete. Il retromarcia di tutto ciò è che se utilizzi intestazioni Cache-Control configurate in modo errato, ad esempio per specificare una durata della cache di lunga durata per un URL senza versione, puoi aggravare le cose aggiungendo i contenuti obsoleti all'API Cache Storage. Ordinare il comportamento della cache HTTP è un prerequisito per l'utilizzo efficace dell'API Cache Storage.

Per quanto riguarda le possibilità che questa nuova API è ora possibile, la risposta è: moltissimo. Alcuni utilizzi comuni che sarebbero difficili o impossibili con solo la cache HTTP includono:

• Usa un approccio di "aggiornamento in background" per i contenuti memorizzati nella cache, noto come stale-while-revalidate.
• Imporre un limite al numero massimo di asset da memorizzare nella cache e implementare un criterio di scadenza personalizzato per rimuovere gli elementi una volta raggiunto questo limite.
• Confronta le risposte di rete precedenti e memorizzate nella cache per vedere se è cambiato qualcosa e consenti all'utente di aggiornare i contenuti (con un pulsante, ad esempio) quando i dati sono stati effettivamente aggiornati.

Per saperne di più, consulta L'API Cache: guida rapida.

Dadi e bulloni dell'API

Ci sono alcuni aspetti da tenere presenti in merito alla progettazione dell'API:

• Gli oggetti Request vengono utilizzati come chiavi univoche durante la lettura e la scrittura in queste cache. Per praticità, puoi passare una stringa URL come 'https://example.com/index.html' come chiave anziché un oggetto Request effettivo e l'API se ne occuperà automaticamente.
• Gli oggetti Response vengono utilizzati come valori in queste cache.
• L'intestazione Cache-Control in un determinato Response viene effettivamente ignorata quando i dati vengono memorizzati nella cache. Non esistono controlli automatici di scadenza o aggiornamento automatici e integrati e, una volta archiviato un elemento nella cache, questo elemento persiste finché il codice non lo rimuove esplicitamente. (Esistono librerie che semplificano la manutenzione della cache per tuo conto. Ne tratteremo più avanti in questa serie.
• A differenza delle API sincrone precedenti come LocalStorage, tutte le operazioni dell'API Cache Storage sono asincrone.

Una rapida deviazione: promesse e asincrone/attendi

I service worker e l'API Cache Storage utilizzano concetti di programmazione asincrona. In particolare, fanno molto affidamento sulle promesse di rappresentare il futuro risultato delle operazioni asincrone. Prima di iniziare, ti consigliamo di acquisire familiarità con le promesse e la relativa sintassi async/await.

Non eseguire il deployment di quel codice... per ora

Anche se forniscono una base importante e possono essere utilizzati così come sono, sia i service worker e l'API Cache Storage sono componenti di base di livello inferiore, con una serie di casi limite e "gotchas". Esistono alcuni strumenti di livello superiore che possono aiutare a semplificare le parti difficili di queste API e fornire tutto il necessario per creare un service worker pronto per la produzione. La prossima guida riguarda uno di questi strumenti: Workbox.