xjcloudy

Offline Storage for Progressive Web Apps – Dev Channel – Medium

xjcloudy · 2017-01-06推荐 · 123阅读 原文链接

The Pokedex.org Progressive Web App uses IndexedDB for application state and the Pokemon data set while the Cache API is used for URL addressable resources.

2016 will hopefully be the year we build for network resilience.

Internet connections can be flakey or non-existent on the go, which is why offline support and reliable performance are common features in Progressive Web Apps. In this post, I’ll summarize some ideas around offline data storagefor PWAs — think the JSON payloads, images and general static data required to provide a meaningful experience offline.

A recommendation for storing data offline:

For URL addressable resources, use the Cache API (part of Service Worker). For all other data, use IndexedDB (with a Promises wrapper).

Some quick answers to common questions on why:

  • Both APIs are asynchronous (IDB is event based and the Cache API is Promise based). They also work in Web Workers, Window and Service Workers.

  • IDB is available everywhere. Service Workers (and the Cache API) are available in Chrome, Firefox, Opera and are in development for Edge.

  • While IDB doesn’t support Promises, several strong libraries giving us Promise wrappers exist. See below for recommendations. The API has mandatory complexity (transactions, schema versioning) that these libraries also try to smooth over where possible.

  • Native support for IDB Promises has been proposed as have observers.

  • How much can you store? In Chrome and Opera: Your storage is per origin (rather than per API). Both storage mechanisms will store data until the browser quota is reached. Apps can check how much quota they’re using with the Quota Management API. Firefox: no limits, but will prompt after 50MB data stored. Mobile Safari: 50MB max, Desktop Safari: unlimited (prompts after 5MB), IE10+ maxes at 250MB and prompts at 10MB. PouchDB track IDB storage behavior. Future facing: For apps requiring more persistent storage, see the on-going work on Durable Storage.

  • Safari 10 has fixed many long-standing IDB bugs in their latest Tech Previews. That said, some folks have run into stability issues with Safari 10’s IDB and PouchDB have found it to be a little slow. Until more research has been done here, YMMV. Please do test and file browser bugs so the folks @webkit and related OSS library authors can take a look. LocalForage, PouchDB, YDN and Lovefield use WebSQL in Safari by default due to UA sniffing (there wasn’t an efficient way to feature-test for broken IDB at the time). This means these libraries will work in Safari 10 without extra effort (just not using IDB directly).

  • URL addressable resources are typically static resources that surprisingly..live at a URL. For PWAs, you could cache the static files composing your application shell (JS/CSS/HTML files) in the Cache API and fill in the offline page data from IndexedDB. There are no hard and fast rules around this however. Some applications might be sufficiently simple that they can just use the Cache API alone while others may find it valuable to partially cache their JSON payloads in IDB so that in browsers without Cache API support you still get the benefit of some local caching during the session.

  • Debugging support for IndexedDB is available in Chrome (Application tab), Opera, Firefox (Storage Inspector) and Safari (see the Storage tab). Debugging IDB is not currently supported in Edge (however, it is possible to debug the underlying JetDB) — vote here for built in support.

IndexedDB Libraries worth checking out

  • localForage(~8KB, Promises, good legacy browser support)

  • idb-keyval (87316* BlockedUnblockFollowFollowing

相关文章