建立一个像应用程序这样的特定书籍阅读器。
主页调用api / booksList并接收包含每本书信息的json数组，例如：
[ { id: server_db_id, title: "title test", sum: 10 , date: ... }
]
在请求后将其缓存，因此不会将书单保存到indexedDB，localStorage或其他存储中。如果我需要一本特定的书，我只需再次调用api书列表并进行过滤即可。那是不好的设计吗？ （本书将超过200个项目）
当用户打开书本时，它也调用/api/book/book_id并对其进行缓存，打开的书本响应是书本行的json列表，例如：
[
{
id: ...
content: "This is line...lore ipsum..."
....
}
]
我将api响应放入vue数据变量中，并使组件正确显示
我没有使用任何类型的处理程序来保持此离线状态。要检测用户是否已经打开这本书，我只需调用api，检查是否发生了错误或响应对象是否有内容。
那是一个错误，错误或愚蠢的决定吗？这会达到配额限制API还是其他种类的限制？ pwa的“神”会向我举起手指说：WAAAT。 （我一开始不使用indexedDB，因为它需要处理一些模型，如果可能的话，我想使事情变得更容易）
答案 0 :(得分：2)
我只是在研究这个问题，并得出结论，此刻，我将继续使用这种方法，在该方法中，我根据资产的匹配路径对资产使用cache，对资产js, css, html使用
然后涉及数据，例如json请求等。最好将它们存储在indexedDB（或等效表）中，它实际上不需要模型或架构。
请参阅Jake Archibald的IndexedDB-Promise库https://github.com/jakearchibald/idb，这很容易使您头脑清醒。
尽管Jake和Addy都说这不是事实上的规则，所以您可以最终确定最适合自己的东西。
这有助于我更好地决定前进的方向。
此处的指南非常擅长引导您完成所需的一切。
PWA祝您好运
使我对此产生疑问的一件事是基于我所看到的一些示例和指南，即数据存储以一种更特殊的方式进行处理。例如，如果PWA调出API，我遇到了两种方法，您可以在其中管理应用程序或服务工作者中的缓存数据，例如如果您的API调用无法在应用程序中获取JSON，则它可以恢复为在indexedDB中获取数据，希望该数据在您的应用程序首次调用API时已预先缓存。
或者您可以使用self.addEventListener('fetch', (event) => { ad-hoc stuff here })来匹配资产或数据请求，并使用缓存或indexedDB响应劫持响应。这样可以避免需要处理应用程序中的脱机数据。
第一种方法让我感到不安，因此我将在服务工作者中同时使用addEventListener方法，因为这就是它的用处，而且我的应用程序也不必为此担心。