与服务人员一起存储REST请求以同步它们 [英] Storing REST requests with service workers to sync them

问题描述

我正在考虑使用服务人员将我的应用程序脱机.我已经通过缓存资源获得了令人满意的结果，但是我还必须检查onfetch是否连接到Internet(如果未连接)-存储请求，然后将其推送到onsync.

我知道，将来的onsync会对此有所帮助，但是我需要-甚至是临时的-解决方案.

我试图将请求存储在worker的数组中，但是它不是持久性的-在计算机重新启动后不起作用(而SW可以工作并提供离线内容).

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

解决方案

在

这可以推广到其他类型的请求，例如HTTP POST，但是需要考虑以下几点:

• 确保您的用户知道他们的HTTP POST正在排队并且将被重播.由于HTTP POST通常会修改服务器端状态，因此，如果由于X个小时的重播请求而导致某些更改，您就不会使用户感到惊讶.
• 根据您正在调用的服务，HTTP POST可能需要有效的Authorization标头.如果您使用OAuth 2进行授权，则它可能会使用寿命有限的访问令牌.重播请求时，先前有效的授权令牌可能已过期.
• IndexedDB是排队请求的一个不错的选择，因为它可以灵活地存储任意数据，例如，无需进行大量工作就可以存储HTTP POST的主体.如果您不能使用IndexedDB(您说使用 Cordova )，那么我唯一想到的其他选择就是尝试使用缓存存储API ，用于创建新的队列"缓存，其中以Request失败作为键，而将空Response对象作为值.在服务工作者启动时，可以在队列"缓存上使用 keys() 方法获取所有Requests的列表，并为每个queuedRequest调用fetch(queuedRequest)进行重播.我以前没有尝试过这种方法，但是我认为它应该可以工作.

I'm thinking about taking my application to offline using service workers. I'm already achieving satisfying results with caching resources, but I also have to check onfetch whether I'm connected to the internet, if not - store the request, and push it onsync.

I understand, that future onsync will help with that, but I need - even temporary - solution for that.

I've tried just to store the requests in an array within worker, but it's not persistent - doesn't work after computer restart (while SW works and serves offline content).

What's the good direction - storing it in cache like files somehow? Or using IndexedDB / SimpleDB (Accessing indexedDB in ServiceWorker. Race condition)?

解决方案

There's an example at https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics of using a service worker to detect failures for certain types of requests (in this case, Google Analytics pings via HTTP GET), and queue up the failures using IndexedDB. The queue is examined each time the service worker starts up and if the request can be successfully "replayed" (because the network is now available), it's removed from the queue. While there are no guarantees about when a service worker will start up (background sync events will help with that in the future), you can safely assume that if the someone is actively using your web app, the service worker will revive itself.

This can be generalized to other types of requests, like HTTP POSTs, but there are a few things to think about:

• Make sure your users are aware that their HTTP POST is being queued and will be replayed. Since HTTP POSTs normally modify server-side state, you don't want to surprise users when something changes as a result of a replayed request that's X hours old.
• Depending on what service you're calling, HTTP POSTs might require a valid Authorization header. If you're using OAuth 2 for authorization, it may use access tokens which have a limited lifespan. A previously valid Authorization token might be expired by the time you replay the request.
• IndexedDB is a good choice for queueing your requests, since it offers flexibility in storing arbitrary data, and it should be possible to, e.g., store the HTTP POST's body without much work. If you can't use IndexedDB (you say it's not supported using Cordova), then the only other option I could think of would be to try to make use of the Cache Storage API to create a new "queue" cache, with failed Requests as the keys and empty Response objects as the values. At service worker startup, you could use the keys() method on your "queue" cache to get a list of all the Requests, and for each queuedRequest, call fetch(queuedRequest) to replay it. I have not tried this approach before, but I think it should work.

这篇关于与服务人员一起存储REST请求以同步它们的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！