Speichern von REST-Anforderungen mit Service-Mitarbeitern, um sie zu synchronisieren

Question

Ich denke darüber nach, meine Anwendung mithilfe von Service-Mitarbeitern offline zu schalten. Ich erziele bereits zufriedenstellende Ergebnisse beim Zwischenspeichern von Ressourcen, aber ich muss auch prüfen, ob ich mit dem Internet verbunden bin, wenn nicht - die Anfrage speichern und auf Onsync schieben.

Ich verstehe, dass zukünftige onsync wird dabei helfen, aber ich brauche - auch temporäre - Lösung dafür.

Ich habe versucht, nur die Anforderungen in einem Array in Worker zu speichern, aber es ist nicht persistent - funktioniert nicht nach dem Neustart des Computers (während SW funktioniert und Offline-Inhalt dient).

Was ist die gute Richtung - Speichern Sie es im Cache wie Dateien irgendwie? Oder mit IndexedDB/SimpleDB (Accessing indexedDB in ServiceWorker. Race condition)?

Answer 1

Es ist ein Beispiel bei https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics einen Servicemitarbeiter der Verwendung von Fehlern für bestimmte Arten von Anfragen zu erfassen (in diesem Fall Google Analytics Pings über HTTP GET) und die Fehler IndexedDB mit Schlange. Die Warteschlange wird jedes Mal überprüft, wenn der Service Worker gestartet wird, und wenn die Anforderung erfolgreich "erneut wiedergegeben" werden kann (weil das Netzwerk jetzt verfügbar ist), wird sie aus der Warteschlange entfernt. Es gibt zwar keine Garantie dafür, wann ein Service-Mitarbeiter gestartet wird (Hintergrundsynchronisierungsereignisse helfen in Zukunft), aber Sie können davon ausgehen, dass der Service-Mitarbeiter sich selbst wiederbelebt, wenn er die Web-App aktiv verwendet.

Dies kann auf andere Arten von Anfragen verallgemeinert werden, wie HTTP POST s, aber es gibt ein paar Dinge zu denken:

• Stellen Sie sicher, Ihre Benutzer sind sich bewusst, dass ihre HTTP POST in der Warteschlange und wird wiedergegeben werden. Da HTTP POST s normalerweise den serverseitigen Status ändert, möchten Sie die Benutzer nicht überraschen, wenn sich aufgrund einer X-Stunden alten Anforderung eine Änderung ergibt.
• Je nachdem, welchen Dienst Sie anrufen, benötigt HTTP POST s möglicherweise einen gültigen Header Authorization. Wenn Sie OAuth 2 für die Autorisierung verwenden, verwendet es möglicherweise Zugriffstoken mit einer begrenzten Lebensdauer. Ein zuvor gültiges Autorisierungstoken ist möglicherweise zu dem Zeitpunkt abgelaufen, zu dem Sie die Anforderung erneut wiedergeben.
• IndexedDB ist eine gute Wahl für die Warteschlange Ihrer Anfragen, da es Flexibilität bietet bei der Speicherung von beliebigen Daten, und es sollte möglich sein, z. B. den Körper der HTTP POST ohne viel Arbeit zu speichern. Wenn Sie IndexedDB nicht verwenden können (Sie sagen, es wird nicht unter Verwendung Cordova unterstützt), dann die einzige andere Option wäre, zu versuchen, die Cache Storage API zu verwenden, um einen neuen "Warteschlange" -Cache zu erstellen, mit fehlgeschlagen Request s als die Schlüssel und leere Response Objekte als die Werte. Beim Start des Service-Mitarbeiters können Sie die keys()-Methode in Ihrem "Queue" -Cache verwenden, um eine Liste aller Requests zu erhalten, und für jede , rufen Sie fetch(queuedRequest), um es erneut zu spielen. Ich habe diesen Ansatz nicht schon einmal ausprobiert, aber ich denke, es sollte funktionieren.