与服务工作者一起存储REST请求以同步它们

Kar*_*cki 9 javascript offline service-worker

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

我明白,未来的onsync将有助于此,但我需要 - 甚至是临时的 - 解决方案.

我曾尝试将请求存储在worker中的数组中,但它不是持久的 - 在计算机重启后不起作用(当SW工作并提供脱机内容时).

什么是好方向 - 以某种方式将其存储在缓存中?或者使用IndexedDB/SimpleDB(在ServiceWorker中访问indexedDB.竞争条件)?

Jef*_*ick 21

https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics上有一个示例,它使用服务工作者来检测某些类型请求的失败(在这种情况下,Google Analytics ping)通过HTTP GET),并使用IndexedDB.排队故障.每次服务工作程序启动时都会检查队列,如果请求可以成功"重放"(因为网络现在可用),则会将其从队列中删除.虽然无法保证服务工作者何时启动(后台同步事件将来会对此有所帮助),但您可以放心地假设,如果有人正在积极使用您的Web应用程序,则服务工作人员将自行恢复.

这可以推广到其他类型的请求,比如HTTP POST,但有几点需要考虑:

  • 确保您的用户知道他们的HTTP POST正在排队并将被重播.由于HTTP POST通常会修改服务器端状态,因此当重播请求超过X小时时,您不希望因某些内容发生更改而让用户感到惊讶.
  • 根据您正在调用的服务,HTTP POST可能需要有效的Authorization标头.如果您使用OAuth 2进行授权,则可能会使用生命周期有限的访问令牌.重播请求时,以前有效的授权令牌可能已过期.
  • IndexedDB是排队请求的一个很好的选择,因为它提供了存储任意数据的灵活性,并且应该可以,例如,存储HTTP POST的主体没有太多工作.如果你不能使用IndexedDB(你说它不支持使用Cordova),那么我唯一能想到的另一个选择就是尝试利用Cache Storage API创建一个新的"队列"缓存,失败的Requests如同键和空Response对象作为值.在服务工作者启动时,您可以使用keys()"队列"缓存中的方法获取所有Requests和每个queuedRequest调用的列表fetch(queuedRequest)以重放它.我之前没有尝试过这种方法,但我认为它应该可行.

  • 任何人都可以提供一个示例,说明如何将HTTP POST的主体存储到IndexedDB中,然后检索它吗? (2认同)