Przechowywanie żądań REST z pracownikami serwisu w celu zsynchronizowania ich

Question

Zastanawiam się nad przeniesieniem aplikacji do trybu offline przy użyciu pracowników serwisu. Osiągam już satysfakcjonujące wyniki z buforowaniem zasobów, ale muszę też sprawdzić, czy pobierane jest połączenie z Internetem, jeśli nie - przechowuj żądanie i przesyłaj je.
Rozumiem, że przyszły onsync pomoże w tym, ale potrzebuję - nawet tymczasowego - rozwiązania tego problemu.

Próbowałem tylko przechowywać żądania w tablicy w ramach procesu roboczego, ale nie jest trwały - nie działa po ponownym uruchomieniu komputera (podczas gdy SW działa i udostępnia treści offline).
Jaki jest dobry kierunek - jakoś przechowywanie go w plikach pamięci podręcznej? Lub używając IndexedDB/SimpleDB (Accessing indexedDB in ServiceWorker. Race condition)?

Answer 1

Jest przykładem na https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics korzystania pracownika serwisu, aby wykryć błędy w odniesieniu do niektórych typów żądań (w tym przypadku, pingi Google Analytics za pośrednictwem protokołu HTTP GET), a w kolejce niepowodzeń przy użyciu IndexedDB. Kolejka jest sprawdzana za każdym razem, gdy pracownik serwisu uruchamia się i jeśli żądanie może zostać pomyślnie "odtworzone" (ponieważ sieć jest już dostępna), jest ona usuwana z kolejki. Chociaż nie ma gwarancji co do tego, kiedy pracownik serwisu uruchomi się (zdarzenia synchronizacji w tle pomogą w przyszłości), można bezpiecznie założyć, że jeśli ktoś aktywnie korzysta z aplikacji internetowej, pracownik serwisu ożywi się.

to można uogólnić na inne rodzaje wniosków, jak HTTP POST s, ale jest kilka rzeczy do przemyślenia:

• Upewnij się, że użytkownicy są świadomi, że ich HTTP POST są ustawiane w kolejce i będzie powtórzyć. Ponieważ HTTP POST zwykle modyfikuje stan po stronie serwera, nie chcesz zaskakiwać użytkowników, gdy coś zmieni się w wyniku powtórnego żądania, które ma X godzin.
• W zależności od usługi, do której dzwonisz, HTTP POST może wymagać prawidłowego nagłówka Authorization. Jeśli korzystasz z autoryzacji OAuth 2 do autoryzacji, może ona korzystać z tokenów dostępu o ograniczonej żywotności. Poprzednio ważny token autoryzacji może wygasnąć przed ponownym odtworzeniem żądania.
• IndexedDB to dobry wybór do kolejkowania żądań, ponieważ zapewnia elastyczność w zapisywaniu dowolnych danych i powinno być możliwe np. Przechowywanie ciała HTTP POST bez większego nakładu pracy. Jeśli nie możesz użyć IndexedDB (mówisz, że nie jest to obsługiwane przy użyciu Cordova), jedyną opcją, o której mógłbym pomyśleć, byłoby skorzystanie z Cache Storage API, aby utworzyć nową pamięć podręczną "kolejki", z błędnymi Request s jako klucze i puste obiekty jako wartości. Podczas uruchamiania pracownika serwisowego można użyć metody keys() w pamięci podręcznej "kolejki", aby uzyskać listę wszystkich Requests, a dla każdego numeru wywołać fetch(queuedRequest), aby odtworzyć ją ponownie. Wcześniej nie próbowałem tego podejścia, ale myślę, że powinno działać.