与 Service Worker 一起存储 REST 请求以同步它们

我正在考虑使用服务人员将我的应用程序离线。我已经通过缓存资源获得了令人满意的结果，但我还必须检查 onfetch 是否连接到互联网，如果没有 - 存储请求，并将其推送到同步。

我知道，未来的 onsync 将对此有所帮助，但我需要 - 即使是临时 - 解决方案。

我尝试将请求存储在工作程序内的数组中，但它不是持久的 - 计算机重新启动后不起作用（而软件可以工作并提供离线内容）。

什么是好的方向 - 以某种方式将其像文件一样存储在缓存中？或者使用 IndexedDB / SimpleDB (访问ServiceWorker中的indexedDB。比赛条件 https://stackoverflow.com/questions/29206836/accessing-indexeddb-in-serviceworker-race-condition/29220096#29220096)?

有一个例子在https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics使用 Service Worker 检测某些类型请求的失败（在本例中，Google Analytics 通过 HTTP 进行 ping）GET），并使用对失败进行排队IndexedDB。每次服务工作线程启动时都会检查队列，如果请求可以成功“重播”（因为网络现在可用），则会将其从队列中删除。虽然无法保证 Service Worker 何时启动（后台同步事件将在将来有所帮助），但您可以放心地假设，如果有人正在积极使用您的 Web 应用程序，Service Worker 将自行恢复。

这可以推广到其他类型的请求，例如 HTTPPOSTs，但有一些事情需要考虑：

• 确保您的用户知道他们的 HTTPPOST正在排队并将重播。自从HTTPPOST通常会修改服务器端状态，因此当由于 X 小时前的重播请求而导致某些内容发生变化时，您不想让用户感到惊讶。
• 根据您调用的服务，HTTPPOSTs 可能需要一个有效的Authorization标头。如果您使用 OAuth 2 进行授权，它可能会使用生命周期有限的访问令牌。当您重播请求时，之前有效的授权令牌可能已过期。
• IndexedDB是对请求进行排队的一个不错的选择，因为它提供了存储任意数据的灵活性，并且应该可以存储 HTTPPOST的身体没有太多的工作。如果你不能使用IndexedDB（你说不支持使用Cordova https://github.com/MobileChromeApps/cordova-plugin-service-worker/blob/master/README.md），那么我能想到的唯一其他选择就是尝试利用缓存存储API https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#cache-objects创建一个新的“队列”缓存，失败Requests 作为键并且为空Response对象作为值。在服务工作线程启动时，您可以使用keys() https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#cache-keys“队列”缓存上的方法来获取所有的列表Requests，并且对于每个queuedRequest, call fetch(queuedRequest)重播它。我以前没有尝试过这种方法，但我认为它应该有效。