Masz progresywną aplikację internetową z skryptem service worker, który umożliwia jej działanie w trybie offline. Świetnie. Masz też skonfigurowaną usługę Google Analytics dla swojej aplikacji internetowej i nie chcesz tracić żadnych statystyk pochodzących z użytkowania w trybie offline. Jeśli jednak spróbujesz wysłać dane do Google Analytics w trybie offline, żądania te się nie powiodą, a dane zostaną utracone.
Rozwiązaniem, co nie powinno Cię dziwić, są skrypty service worker. Dokładnie rzecz biorąc, do usługi workera jest dodawany kod, który przechowuje żądania Google Analytics (za pomocą IndexedDB) i próbuje je ponownie wykonać później, gdy sieć będzie dostępna. Udostępniliśmy kod do obsługi tej logiki w ramach otwartego kodu źródłowego aplikacji internetowej Google I/O, ale zdaliśmy sobie sprawę, że jest to przydatny wzorzec, a kopiowanie i wklejanie kodu może być niestabilne.
Z przyjemnością informujemy, że wszystko, czego potrzebujesz do obsługi żądań Google Analytics w trybie offline w Twoim serwisie workera, zostało zebrane w jednym pakiecie npm: npm install --save-dev sw-offline-google-analytics
Korzystanie z sw-offline-google-analytics
W obecnym kodzie usługi dodaj:
// This code should live inside your service worker JavaScript, ideally
// before any other 'fetch' event handlers are defined:
// First, import the library into the service worker global scope:
importScripts('path/to/offline-google-analytics-import.js');
// Then, call goog.offlineGoogleAnalytics.initialize():
// See https://github.com/GoogleChrome/workbox/tree/main/packages/workbox-google-analytics
goog.offlineGoogleAnalytics.initialize();
// At this point, implement any other service worker caching strategies
// appropriate for your web app.
To już wszystko.
Co się dzieje w tle?
sw-offline-google-analytics konfiguruje w usługach wtyczki nowego przetwarzającego zdarzenie fetch, który odpowiada na żądania wysyłane do domeny Google Analytics. (biblioteka ignoruje żądania spoza Google Analytics, co umożliwia innym obsługom zdarzeń fetch w usługach workerów implementowanie odpowiednich strategii dotyczących tych zasobów). Najpierw spróbuje zrealizować żądanie w sieci. Jeśli użytkownik jest online, wszystko będzie działać normalnie.
Jeśli żądanie sieci się nie powiedzie, biblioteka automatycznie zapisze informacje o żądaniu w IndexedDB wraz z znacznikiem czasu wskazującym, kiedy żądanie zostało pierwotnie wysłane. Za każdym razem, gdy usługa zostaje uruchomiona, biblioteka sprawdza kolejkę żądań i próbuje je ponownie wysłać wraz z kilkoma dodatkowymi parametrami Google Analytics:
- parametr
qt, który jest ustawiany na czas, jaki upłynął od momentu wysłania żądania, aby zapewnić prawidłowe przypisanie pierwotnego czasu. - dowolne dodatkowe parametry i wartości podane w właściwości
parameterOverridesobiektu konfiguracji przekazanego dogoog.offlineGoogleAnalytics.initialize(). Możesz na przykład dodać wymiar niestandardowy, aby odróżnić żądania wysłane ponownie przez service workera od tych wysłanych natychmiast.
Jeśli ponowne wysłanie żądania się powiedzie, to świetnie. Prośba zostaje usunięta z IndexedDB. Jeśli ponowna próba się nie powiedzie, a pierwotne żądanie zostało wysłane mniej niż 24 godziny temu, zostanie ono zachowane w IndexedDB, aby można było je powtórzyć przy następnym uruchomieniu pracownika usługi. Pamiętaj, że nie gwarantujemy przetwarzania danych Google Analytics starszych niż 4 godziny, ale ponowne wysłanie nieco starszych danych „na wszelki wypadek” nie zaszkodzi.
sw-offline-google-analytics implements też strategię najpierw sieć, a potem pamięć podręczna dla rzeczywistego analytics.jskodu JavaScript, którego potrzeba do inicjowania Google Analytics.
Wkrótce pojawi się więcej informacji.
sw-offline-google-analytics jest częścią większego projektu sw-helpers, czyli zbioru bibliotek, które mają na celu zapewnienie ulepszeń w dotychczasowych implementacjach usług działających w tle.
W ramach tego projektu znajduje się też biblioteka sw-appcache-behavior, która implementuje strategie buforowania zdefiniowane w dotychczasowym pliku manifestu AppCache w ramach usługi workera. Ma ona pomóc Ci w przejściu z AppCache na service workery przy zachowaniu spójnej strategii dotyczącej pamięci podręcznej, przynajmniej na początku.
Jeśli masz inne pomysły dotyczące biblioteki, chętnie się o nich dowiemy. Prześlij prośbę w narzędziu do zgłaszania problemów.