Service worker e API Cache Storage

Jeff Posnick

Non riesci a ottenere un'affidabilità della rete. La cache HTTP del browser è la tua prima linea di difesa, ma come hai appreso, è davvero efficace solo quando carichi URL con versione che hai visitato in precedenza. La cache HTTP da sola non è sufficiente.

Fortunatamente, sono disponibili due strumenti più recenti per aiutarti a cambiare le cose in tuo favore: service worker e l'API Cache Storage. Poiché vengono utilizzati così spesso insieme, vale la pena conoscerli entrambi contemporaneamente.

Service worker

Un worker del servizio è integrato nel browser e controllato da un po' di codice JavaScript aggiuntivo che devi creare. Lo esegui insieme agli altri file che compongono la tua applicazione web effettiva.

Un worker di servizio ha alcuni poteri speciali. Tra le altre funzioni, attende pazientemente che la tua app web effettui una richiesta in uscita, quindi entra in azione intercettandola. Sta a te decidere cosa deve fare il service worker con questa richiesta intercettata.

Per alcune richieste, la soluzione migliore potrebbe essere semplicemente consentire alla richiesta di continuare sulla rete, come accadrebbe se non fosse presente alcun servizio worker.

Per altre richieste, però, puoi utilizzare qualcosa di più flessibile della cache HTTP del browser e restituire una risposta rapida e affidabile senza dover preoccuparti della rete. Ciò comporta l'utilizzo dell'altro pezzo del puzzle: l'API Cache Storage.

L'API Cache Storage

L'API Cache Storage apre una nuova gamma di possibilità, offrendo agli sviluppatori il controllo completo sui contenuti della cache. Anziché basarsi su una combinazione di intestazioni HTTP e delle euristiche integrate del browser, l'API Cache Storage espone un approccio alla memorizzazione nella cache basato sul codice. L'API Cache Storage è particolarmente utile quando viene chiamata dal codice JavaScript del tuo service worker.

Aspetta… ora c'è un'altra cache da considerare?

Probabilmente ti starai chiedendo, ad esempio, "Devo comunque configurare le mie intestazioni HTTP?" e "Cosa posso fare con questa nuova cache che non era possibile con la cache HTTP?" Non preoccuparti, sono reazioni naturali.

Ti consigliamo comunque di configurare le intestazioni Cache-Control sul tuo server web, anche se sai di utilizzare l'API Cache Storage. In genere, 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 della versione, come gli hash.

Quando compila la cache dell'API Cache Storage, il browser controlla per impostazione predefinita la presenza di voci esistenti nella cache HTTP e le utilizza se le trova. Se aggiungi URL con versione alla cache dell'API Cache Storage, il browser evita un'ulteriore richiesta di rete. Il lado opposto della medaglia è che, se utilizzi intestazioni Cache-Control configurate in modo errato, ad esempio specificando una durata della cache a lungo termine per un URL senza versione, potresti aggravare la situazione aggiungendo contenuti obsoleti all'API Cache Storage. Ordinare il comportamento della cache HTTP è un prerequisito per utilizzare efficacemente l'API Cache Storage.

In merito a ciò che ora è possibile con questa nuova API, la risposta è: molto. Alcuni utilizzi comuni che sarebbero difficili o impossibili solo con la cache HTTP includono:

• Utilizza un approccio di "aggiornamento in background" per i contenuti memorizzati nella cache, noto come stale-while-revalidate.
• Imposta un limite al numero massimo di asset da memorizzare nella cache e implementa una policy di scadenza personalizzata per rimuovere gli elementi una volta raggiunto il limite.
• Confronta le risposte della rete memorizzate nella cache in precedenza con quelle aggiornate per vedere se c'è qualche cambiamento e consenti all'utente di aggiornare i contenuti (ad esempio con un pulsante) quando i dati sono stati effettivamente aggiornati.

Per saperne di più, consulta la guida rapida all'API Cache.

Aspetti pratici dell'API

Ecco alcuni aspetti da tenere in considerazione in merito alla progettazione dell'API:

• Gli oggetti Request vengono utilizzati come chiavi univoche durante la lettura e la scrittura in queste cache. Per comodità, puoi passare una stringa URL come 'https://example.com/index.html' come chiave anziché un oggetto Request effettivo e l'API gestirà automaticamente la richiesta.
• Gli oggetti Response vengono utilizzati come valori in queste cache.
• L'intestazione Cache-Control in un determinato Response viene ignorata di fatto quando si memorizza nella cache i dati. Non sono disponibili controlli automatici di scadenza o aggiornamento integrati e, una volta memorizzato un elemento nella cache, questo rimarrà finché il codice non lo rimuoverà esplicitamente. Esistono librerie per semplificare la gestione della cache per tuo conto. che verranno trattati più avanti in questa serie.
• A differenza delle API sincrone precedenti come LocalStorage, tutte le operazioni dell'API Cache Storage sono asincrone.

Una breve deviazione: promesse e async/await

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

Non eseguire il deployment del codice… per il momento

Sebbene forniscano una base importante e possano essere utilizzati così come sono, sia i worker di servizio sia l'API Cache Storage sono in effetti componenti di base di livello inferiore, con una serie di casi limite e "spunti". Esistono alcuni strumenti di livello superiore che possono aiutarti a gestire le parti più complesse di queste API e fornirti tutto ciò di cui hai bisogno per creare un servizio worker pronto per la produzione. La guida successiva illustra uno di questi strumenti: Workbox.