Trudno Ci zadbać o niezawodność sieci. Pamięć podręczna HTTP przeglądarki to pierwsza linia obrony, ale, jak już wiesz, jest naprawdę skuteczna tylko wtedy, gdy wczytujesz już odwiedzone wcześniej różne wersje adresów URL. Pamięć podręczna HTTP jest niewystarczająca.
Na szczęście istnieją 2 nowsze narzędzia, które mogą odwrócić bieg wydarzeń: service Works i Cache Storage API. Ponieważ są one tak często wykorzystywane razem, warto poznać oba w tym samym czasie.
Skrypty service worker
Skrypt service worker jest wbudowany w przeglądarkę i kontrolowany przez dodatkowy kod JavaScript, który jest odpowiedzialny za jego utworzenie. Wdrażasz go razem z innymi plikami składającymi się na Twoją aplikację internetową.
Skrypt service worker ma pewne specjalne uprawnienia. Poza innymi zadaniami cierpliwie czeka, aż Twoja aplikacja internetowa wyśle żądanie wychodzące, a następnie podejmuje działanie, przechwytując je. Sposób, w jaki skrypt service worker robi z tym przechwyconym żądaniem, zależy od Ciebie.
W przypadku niektórych żądań najlepszym rozwiązaniem może być po prostu zezwolenie na ich kontynuację w sieci, tak jak w przypadku braku skryptu service worker.
W przypadku innych żądań możesz jednak wykorzystać coś bardziej uniwersalnego niż pamięć podręczna HTTP przeglądarki i zwracać niezawodnie szybką odpowiedź bez obaw o działanie sieci. Wiąże się to z wykorzystaniem drugiego elementu układanki: interfejsu Cache Storage API.
Interfejs Cache Storage API
Interfejs Cache Storage API otwiera zupełnie nowe możliwości, ponieważ zapewnia programistom pełną kontrolę nad zawartością pamięci podręcznej. Zamiast korzystać z kombinacji nagłówków HTTP i wbudowanej heuristics przeglądarki, interfejs Cache Storage API udostępnia oparte na kodzie podejście do buforowania. Interfejs Cache Storage API jest szczególnie przydatny w przypadku wywołania z kodu JavaScript skryptu service worker.
Chwileczkę... Czy jest teraz kolejna pamięć podręczna, nad którą można się zastanowić?
Pewnie zadajesz sobie pytania: „Czy nadal muszę skonfigurować nagłówki HTTP?” i „Co mogę zrobić z nową pamięcią podręczną, która nie była dostępna dzięki pamięci podręcznej HTTP?”. Nie martw się – to naturalne reakcje.
Nawet jeśli wiesz, że używasz interfejsu Cache Storage API, nadal zalecamy skonfigurowanie nagłówków Cache-Control na serwerze WWW. Zwykle można pominąć ustawienie Cache-Control: no-cache w przypadku adresów URL bez wersji lub Cache-Control: max-age=31536000 w przypadku adresów URL, które zawierają informacje o obsłudze wersji, takie jak hasze.
Podczas zapełniania pamięci podręcznej interfejsu Cache Storage API przeglądarka domyślnie sprawdza, czy w pamięci podręcznej HTTP są wpisy, i używa ich w przypadku ich znalezienia. Jeśli dodajesz do pamięci podręcznej interfejsu Cache Storage API różne wersje adresów URL, przeglądarka omija dodatkowe żądanie sieciowe. Z drugiej strony użycie błędnie skonfigurowanych nagłówków Cache-Control, np. określenie długiego okresu przechowywania w pamięci podręcznej dla niewersjonowanego adresu URL, może pogorszyć problem przez dodanie nieaktualnych treści do interfejsu Cache Storage API. Uporządkowanie działania pamięci podręcznej HTTP jest niezbędne do efektywnego korzystania z interfejsu Cache Storage API.
Jeśli chodzi o możliwości, jakie daje ten nowy interfejs API, odpowiedź brzmi: w dużym stopniu. Oto niektóre typowe zastosowania, które byłyby trudne lub niemożliwe do wykorzystania tylko z pamięci podręcznej HTTP:
- Stosuj podejście „odświeżaj w tle” do zawartości pamięci podręcznej, co określa się mianem „stale podczas ponownej weryfikacji”.
- Możesz wprowadzić limit maksymalnej liczby zasobów, które mają być przechowywane w pamięci podręcznej, i zaimplementować niestandardową zasadę wygasania, aby usuwać elementy po osiągnięciu limitu.
- Porównaj wcześniejsze i aktualne odpowiedzi sieci, aby sprawdzić, czy coś się zmieniło, i umożliwi użytkownikowi aktualizowanie treści (np. za pomocą przycisku), gdy dane rzeczywiście zostały zaktualizowane.
Więcej informacji znajdziesz w artykule Interfejs API pamięci podręcznej: krótki przewodnik.
Śruby i nakrętki do interfejsu API
Jeśli chodzi o projekt interfejsu API, warto pamiętać o tych kwestiach:
- Obiekty
Requestsą używane jako unikalne klucze podczas odczytywania i zapisywania w tych pamięciach podręcznych. Dla ułatwienia możesz przekazywać jako klucz ciąg adresu URL, taki jak'https://example.com/index.html', zamiast rzeczywistego obiektuRequest. Interfejs API zrobi to automatycznie za Ciebie. Responsesą używane jako wartości w tych pamięciach podręcznych.- Nagłówek
Cache-Controlw obrębie danego elementuResponsejest skutecznie ignorowany podczas buforowania danych. Nie ma wbudowanych mechanizmów sprawdzania daty ważności ani aktualności, a element zapisany w pamięci podręcznej pozostaje w pamięci podręcznej, dopóki kod nie usunie go bezpośrednio. Istnieją biblioteki, które ułatwiają obsługę pamięci podręcznej w Twoim imieniu. 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 objazd: obietnice i asynchronizacja/oczekiwanie
Skrypty service worker i interfejs Cache Storage API wykorzystują koncepcje programowania asynchronicznego.
W szczególności polegają na obietnicach przedstawiania przyszłych wyników operacji asynchronicznych. Zanim zaczniesz, zapoznaj się z obietnicami i powiązaną z nią składnią async/await.
Jeszcze nie wdrażaj tego kodu
Choć stanowią one ważne podstawy i można ich używać w niezmienionej formie, zarówno mechanizmy Service Worker, jak i Cache Storage API są elementami składowymi niższego poziomu, z licznymi przypadkami brzegowymi i tzw. „gotchami”. Istnieją narzędzia wyższego poziomu, które pomogą Ci uporać się z trudnymi kwestiami związanymi z tymi interfejsami API i udostępnią wszystko, czego potrzebujesz do utworzenia skryptu service worker gotowy do wykorzystania w środowisku produkcyjnym. W następnym przewodniku omawiamy jedno z takich narzędzi: Workbox.