有人知道在OfflineFirst设计中针对客户端缓存策略的聪明或标准解决方案。
我有一个Ionic2（Angular2 / TypeScript）客户端，我正在尝试遵循OfflineFirst原则，所以假设有一个不可预测的连接。我想只下载以多对多方式共享的对象，这些对象自上次客户端更新以来已发生更改，并且仅更改自上次更新以来的更改，才更新客户端的本地存储。
这是我目前的印象： - 任何推送策略似乎都没有意义，因为离线先行？所以一些建议是使用Observable / Observer模式，但这使用Push策略，我认为这不是一个很好的解决方案。 - 我考虑过在服务器上存储user-lastupdate键值对以及每个对象的lastupdate ts，然后在每次客户端联机并ping新的更新时比较2。如果有更新，则下载那些比上次用户更新ts更新的对象。 - 我也看到一些提到服务工作者，但我不熟悉它。 - 其他人选择昂贵的解决方案，只需在定期ping上完全刷新，即每天，每4小时左右。
任何见解都会很精彩。
答案 0 :(得分：0)
我在使用CouchDB（或Cloudant等相关技术）的Offline First应用程序中使用的典型模式是执行所谓的one-database-per-user。基本思想是在注册应用程序时为每个用户分配一个CouchDB数据库。然后，只允许每个用户读/写该用户的CouchDB数据库。像Hoodie或Cloudant Envoy这样的工具（Envoy为客户提供了每个用户一个数据库的“错觉”）可以帮助解决这个问题：
这种方法适用于具有良好分段的用户数据（例如个人TODO列表）的应用程序，并且可以很好地扩展。但是，当您希望在用户之间共享数据（例如共享TODO列表），或者您希望跨用户对聚合数据进行分析时，该方法会带来挑战。
您的应用似乎属于此“用户之间的共享数据”类别。面临的挑战是，如何将用户数据库A中的共享数据导入用户数据库B？在CouchDB中，这个共享数据将表示为JSON文档。
一种体系结构是使用消息队列，并为每个用户数据库分配一个发布者和订阅者代理。这些代理将在您的安全策略中在服务器端运行，以获取对哪些数据具有访问权限的人员。这些代理将订阅其他用户数据库中的数据“通道”，并在另一方面发布到数据的“通道”。这些通道可以由数据库中的文档中包含的特定属性定义。当代理检测到描述的事件时，它会运行筛选复制，以将有问题的数据从一个用户数据库复制到另一个用户数据库。