Skrypty service worker i interfejs Cache Storage API

Jeff Posnick

walczysz o stabilność sieci. Pamięć podręczna HTTP przeglądarki to pierwsza linia obrony, ale jak już wiesz, jest ona naprawdę skuteczna tylko podczas wczytywania adresów URL z wersjami, które były już wcześniej odwiedzane. Sam bufor HTTP nie wystarczy.

Na szczęście istnieją 2 nowsze narzędzia, które mogą pomóc Ci w zmianie sytuacji na swoją korzyść: service worker i interfejs Cache Storage API. Ponieważ są one często używane razem, warto poznać je jednocześnie.

Skrypty service worker

Usługa robocza jest wbudowana w przeglądarkę i sterowana przez dodatkowy kod JavaScript, który musisz utworzyć. Rozmieszczasz go razem z innymi plikami, które składają się na Twoją aplikację internetową.

Usługa ma pewne specjalne uprawnienia. Oprócz innych zadań, cierpliwie czeka na to, aż Twoja aplikacja internetowa wyśle żądanie, a potem przechwytuje je. To, co usługa robocza zrobi z przechwyconym żądaniem, zależy od Ciebie.

W przypadku niektórych żądań najlepszym rozwiązaniem może być po prostu przepuszczenie żądania do sieci, tak jakby w ogóle nie było pracownika obsługi klienta.

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

Interfejs Cache Storage API

Interfejs Cache Storage API otwiera przed deweloperami zupełnie nowe możliwości, ponieważ daje im pełną kontrolę nad zawartością pamięci podręcznej. Zamiast polegać na połączeniu nagłówków HTTP i wbudowanych heurystycznych mechanizmów przeglądarki, interfejs Cache Storage API oferuje podejście do buforowania oparte na kodzie. Interfejs Cache Storage API jest szczególnie przydatny, gdy jest wywoływany z JavaScriptu w usługach workerów.

Poczekaj… czy teraz mamy się zastanowić nad jeszcze innym poziomem pamięci podręcznej?

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

Zalecamy skonfigurowanie nagłówków Cache-Control na serwerze WWW, nawet jeśli wiesz, że używasz interfejsu Cache Storage API. W przypadku adresów URL bez wersji zazwyczaj możesz ustawić wartość Cache-Control: no-cache lub Cache-Control: max-age=31536000 w przypadku adresów URL zawierających informacje o wersjach, np. sumy kontrolne.

Podczas wypełniania pamięci podręcznej interfejsu API pamięci podręcznej przeglądarka domyślnie sprawdza, czy w pamięci podręcznej HTTP znajdują się istniejące wpisy, i używa ich, jeśli je znajdzie. Jeśli do pamięci podręcznej interfejsu API pamięci podręcznej dodasz adresy URL z wersjami, przeglądarka nie będzie musiała wysyłać dodatkowego żądania sieciowego. Z drugiej strony, jeśli używasz nieprawidłowo skonfigurowanych nagłówków Cache-Control, na przykład ustawiasz długi okres istnienia pamięci podręcznej dla niewersyjnego adresu URL, 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ć zachowanie pamięci podręcznej HTTP.

Co można teraz zrobić dzięki temu nowemu interfejsowi API? Wiele. Oto kilka typowych zastosowań, które byłyby trudne lub niemożliwe do zrealizowania przy użyciu tylko pamięci podręcznej HTTP:

• Stosuj podejście „odświeżanie w tle” do treści przechowywanych w pamięci podręcznej, znane jako „stale-while-revalidate”.
• Określ maksymalną liczbę zasobów do umieszczenia w pamięci podręcznej i zastosuj niestandardową zasadę wygaśnięcia, 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 pozwalaj użytkownikowi na aktualizowanie treści (np. za pomocą przycisku) po faktycznej aktualizacji danych.

Aby dowiedzieć się więcej, zapoznaj się z krótkim przewodnikiem po interfejsie Cache API.

Szczegóły dotyczące interfejsu API

Podczas projektowania interfejsu API należy pamiętać o kilku kwestiach:

• Obiekty Request są używane jako unikalne klucze podczas odczytu i zapisu do tych pamięci podręcznych. Dla wygody możesz przekazać jako klucz ciąg znaków adresu URL, np. 'https://example.com/index.html', zamiast rzeczywistego obiektu Request, a interfejs API automatycznie to obsłuży.
• Response obiekty 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 żadnych wbudowanych automatycznych mechanizmów sprawdzania ważności ani aktualności. Gdy przechowasz element w pamięci podręcznej, będzie on w niej przechowywany, dopóki kod nie usunie go w sposób jawny. (Istnieją biblioteki, które upraszczają konserwację pamięci podręcznej). Omówimy je w późniejszych częściach tej serii.)
• W przeciwieństwie do starszych, synchronicznych interfejsów API, takich jak LocalStorage, wszystkie operacje interfejsu Cache Storage API są asynchroniczne.

Krótkie wprowadzenie: obietnice i asynchroniczne oczekiwanie

Usługi w tle i interfejs Cache Storage API korzystają z koncepcji programowania asynchronicznego. W szczególności polegają one w dużej mierze na obietnicach dotyczących przyszłego wyniku operacji asynchronicznych. Zanim zaczniesz, zapoznaj się z obietnicami i powiązaną z nimi składnią async/await.

Nie wdrażaj jeszcze tego kodu…

Chociaż stanowią one ważną podstawę i mogą być używane w postaci, w której zostały udostępnione, zarówno service workers, jak i Cache Storage API są w istocie elementami składowymi niskiego poziomu, z liczną liczbą przypadków szczególnych i „gotchas”. Istnieją narzędzia wyższego poziomu, które mogą ułatwić Ci trudne aspekty tych interfejsów API i zapewnić wszystko, czego potrzebujesz do tworzenia gotowych do wdrożenia usług typu service worker. W następnym przewodniku omówimy jedno z takich narzędzi: Workbox.