Service worker e API Cache Storage

Jeff Posnick

Sei impegnato in una lotta per l'affidabilità della rete. La cache HTTP del browser è la tua 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 nuovi strumenti per aiutarti a invertire la tendenza a tuo favore: i service worker e l'API Storage della cache. Poiché vengono spesso utilizzati insieme, vale la pena conoscerli entrambi contemporaneamente.

Service worker

Un service worker è integrato nel browser e controllato da un po' di codice JavaScript aggiuntivo che devi creare tu. Puoi eseguirne il deployment insieme agli altri file che compongono la tua applicazione web effettiva.

Un service worker ha alcuni poteri speciali. Tra le altre cose, attende pazientemente che la tua app web effettui una richiesta in uscita e poi entra in azione intercettandola. Cosa fa il service worker con questa richiesta intercettata dipende da te.

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

Per altre richieste, tuttavia, puoi sfruttare qualcosa di più flessibile della cache HTTP del browser e restituire una risposta affidabile e veloce senza doverti preoccupare della rete. Ciò comporta l'utilizzo dell'altro pezzo del puzzle: l'API Cache Storage.

API Storage Cache

Browser Support

  • Chrome: 43.
  • Edge: 16.
  • Firefox: 41.
  • Safari: 11.1.

Source

L'API Cache Storage apre una gamma completamente nuova di possibilità, offrendo agli sviluppatori il controllo completo sui contenuti della cache. Anziché fare affidamento su una combinazione di intestazioni HTTP e sulle 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 service worker.

Aspetta… ora c'è un'altra cache a cui pensare?

Probabilmente ti starai chiedendo: "Devo ancora 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 che stai utilizzando l'API Storage Cache. In genere, puoi cavartela impostando 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 compila la cache dell'API Storage Cache, 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 una richiesta di rete aggiuntiva. Il rovescio della medaglia è che se utilizzi intestazioni Cache-Control configurate in modo errato, ad esempio specificando una durata della cache di lunga durata per un URL senza versione, puoi finire per peggiorare le cose aggiungendo contenuti obsoleti all'API Cache Storage. La corretta configurazione del comportamento della cache HTTP è un prerequisito per l'utilizzo efficace dell'API Cache Storage.

Per quanto riguarda ciò che è ora possibile fare con questa nuova API, la risposta è: molto. Alcuni usi comuni che sarebbero difficili o impossibili con la sola cache HTTP includono:

  • Utilizza un approccio di "aggiornamento in background" ai contenuti memorizzati nella cache, noto come stale-while-revalidate.
  • Imponi 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 questo limite.
  • Confronta le risposte di rete memorizzate nella cache in precedenza con quelle aggiornate per vedere se è cambiato qualcosa 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 The Cache API: A quick guide.

Nozioni di base sulle API

Ecco alcuni aspetti da tenere presente sulla 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 la gestirà automaticamente.
  • Gli oggetti Response vengono utilizzati come valori in queste cache.
  • L'intestazione Cache-Control su un determinato Response viene ignorata di fatto durante la memorizzazione dei dati nella cache. Non esistono controlli automatici integrati di scadenza o aggiornamento e, una volta archiviato un elemento nella cache, questo rimarrà lì finché il codice non lo rimuove esplicitamente. (Esistono librerie per semplificare la manutenzione della cache per tuo conto. Questi argomenti verranno trattati più avanti in questa serie.
  • A differenza delle API sincrone meno recenti, come LocalStorage, tutte le operazioni dell'API Cache Storage sono asincrone.

Una breve deviazione: Promise e async/await

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

Non eseguire il deployment del codice… per ora

Sebbene forniscano una base importante e possano essere utilizzati così come sono, sia i service worker sia l'API Storage Cache sono di fatto componenti di base di livello inferiore, con una serie di casi limite e "trappole". Esistono alcuni strumenti di livello superiore che possono aiutarti a semplificare le parti difficili di queste API e fornire tutto ciò di cui hai bisogno per creare un service worker pronto per la produzione. La prossima guida illustra uno di questi strumenti: Workbox.