Skrypty service worker i interfejs Cache Storage API

Jeff Posnick

Walczysz o niezawodność sieci. Pamięć podręczna HTTP przeglądarki to pierwsza linia obrony, ale jak już wiesz, jest ona skuteczna tylko podczas wczytywania adresów URL z wersjami, które zostały wcześniej odwiedzone. Sama pamięć podręczna HTTP nie wystarczy.

Na szczęście dostępne są 2 nowsze narzędzia, które mogą pomóc Ci odwrócić sytuację na Twoją korzyść: skrypty service worker i interfejs Cache Storage API. Ponieważ są one często używane razem, warto poznać je oba jednocześnie.

Skrypty service worker

Skrypt service worker jest wbudowany w przeglądarkę i kontrolowany przez dodatkowy kod JavaScript, który musisz utworzyć. Wdrażasz go razem z innymi plikami, które składają się na Twoją aplikację internetową.

Skrypt service worker ma pewne specjalne uprawnienia. Jednym z jego zadań jest cierpliwe czekanie, aż aplikacja internetowa wyśle żądanie wychodzące, a następnie przechwycenie go. To, co skrypt service worker zrobi z przechwyconym żądaniem, zależy od Ciebie.

W przypadku niektórych żądań najlepszym rozwiązaniem może być po prostu zezwolenie na ich dalsze przesyłanie do sieci, tak jakby nie było żadnego skryptu service worker.

W przypadku innych żądań możesz jednak skorzystać z czegoś bardziej elastycznego niż pamięć podręczna HTTP przeglądarki i zwrócić niezawodną, szybką odpowiedź bez konieczności martwienia się o sieć. Wymaga to użycia innego elementu układanki: interfejsu Cache Storage API.

Cache Storage API

Browser Support

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

Source

Interfejs Cache Storage API otwiera zupełnie nowe możliwości, dając deweloperom pełną kontrolę nad zawartością pamięci podręcznej. Zamiast polegać na kombinacji nagłówków HTTP i wbudowanych heurystyk przeglądarki, interfejs Cache Storage API udostępnia podejście do buforowania oparte na kodzie. Interfejs Cache Storage API jest szczególnie przydatny, gdy jest wywoływany z poziomu kodu JavaScript skryptu service worker.

Zaraz… jest jeszcze jedna pamięć podręczna, o której trzeba pamiętać?

Pewnie zastanawiasz się, czy nadal musisz konfigurować nagłówki HTTP i co możesz zrobić z nową pamięcią podręczną, czego nie można było zrobić z pamięcią podręczną HTTP. Nie martw się – to naturalne reakcje.

Nadal zalecamy skonfigurowanie nagłówków Cache-Control na serwerze WWW, nawet jeśli wiesz, że używasz interfejsu Cache Storage API. Zwykle wystarczy ustawić Cache-Control: no-cache dla adresów URL bez wersji lub Cache-Control: max-age=31536000 dla adresów URL zawierających informacje o obsłudze wersji, np. hasze.

Podczas wypełniania pamięci podręcznej interfejsu Cache Storage API przeglądarka domyślnie sprawdza, czy w pamięci podręcznej HTTP nie ma już istniejących wpisów, i używa ich, jeśli je znajdzie. Jeśli dodasz adresy URL z wersjami do pamięci podręcznej interfejsu Cache Storage API, przeglądarka uniknie dodatkowego żądania sieciowego. Z drugiej strony, jeśli używasz nieprawidłowo skonfigurowanych nagłówków Cache-Control, np. określasz długi czas przechowywania w pamięci podręcznej adresu URL bez wersji, możesz pogorszyć sytuację, dodając nieaktualne treści do interfejsu Cache Storage API. Aby skutecznie korzystać z interfejsu Cache Storage API, musisz najpierw uporządkować działanie pamięci podręcznej HTTP.

Nowy interfejs API daje wiele możliwości. Oto kilka typowych zastosowań, które byłyby trudne lub niemożliwe do zrealizowania przy użyciu samej pamięci podręcznej HTTP:

  • Użyj podejścia „odświeżanie w tle” do treści z pamięci podręcznej, znanego jako stale-while-revalidate.
  • Nałóż limit na maksymalną liczbę zasobów do zapisania w pamięci podręcznej i wdroż niestandardową zasadę wygasania, aby usuwać elementy po osiągnięciu tego limitu.
  • Porównaj wcześniej zapisane w pamięci podręcznej i nowe odpowiedzi sieci, aby sprawdzić, czy coś się zmieniło, i umożliwić użytkownikowi zaktualizowanie treści (np. za pomocą przycisku), gdy dane zostaną faktycznie zaktualizowane.

Więcej informacji znajdziesz w krótkim przewodniku po interfejsie Cache API.

Podstawowe informacje o interfejsie API

Oto kilka kwestii, o których warto pamiętać w związku z interfejsem API:

  • Obiekty Request są używane jako unikalne klucze podczas odczytu i zapisu w tych pamięciach podręcznych. Dla wygody możesz przekazać ciąg adresu URL, np. 'https://example.com/index.html', jako klucz zamiast rzeczywistego obiektu Request, a interfejs API automatycznie go obsłuży.
  • Obiekty Response są używane jako wartości w tych pamięciach podręcznych.
  • Nagłówek Cache-Control w danym Response jest ignorowany podczas zapisywania danych w pamięci podręcznej. Nie ma automatycznych, wbudowanych mechanizmów sprawdzania ważności ani aktualności. Gdy zapiszesz element w pamięci podręcznej, pozostanie on tam, dopóki Twój kod wyraźnie go nie usunie. (Istnieją biblioteki, które upraszczają zarządzanie pamięcią podręczną. Omówimy je w dalszej części tej serii).
  • W przeciwieństwie do starszych, synchronicznych interfejsów API, takich jak LocalStorage, wszystkie operacje interfejsu Cache Storage API są asynchroniczne.

Krótka dygresja: obiekty Promise i async/await

Skrypty service worker i interfejs Cache Storage API korzystają z koncepcji programowania asynchronicznego. W szczególności opierają się na obietnicach, które reprezentują przyszły wynik operacji asynchronicznych. Zanim zaczniesz, zapoznaj się z obietnicami i powiązaną składnią async/await.

Nie wdrażaj jeszcze tego kodu

Chociaż stanowią one ważną podstawę i mogą być używane w obecnej formie, zarówno skrypty service worker, jak i interfejs Cache Storage API są w rzeczywistości elementami składowymi niższego poziomu, z wieloma przypadkami skrajnymi i „pułapkami”. Istnieją pewne narzędzia wyższego poziomu, które mogą pomóc w uproszczeniu trudnych elementów tych interfejsów API i zapewnić wszystko, czego potrzebujesz do utworzenia skryptu service worker gotowego do wykorzystania w środowisku produkcyjnym. W następnym przewodniku omówimy jedno z takich narzędzi: Workbox.