2017-08-11 160 views
0

有谁知道OfflineFirst设计中客户端缓存策略的聪明或标准解决方案吗?需要针对移动客户端w共享对象的OfflineFirst客户端缓存策略

我有一个Ionic2(Angular2/TypeScript)客户端,我试图遵循OfflineFirst的原则,所以假设有一个不可预知的连接。我只想下载多个用户共享的对象,以多对多关系形式存在,这些对象自上次客户端更新以来发生了更改,并且仅在上次更新后才更新客户端的本地存储。

这里是我目前的印象: - 任何推送策略似乎没有意义,因为首先离线?所以一些建议是使用Observable/Observer模式,但是这使用了Push策略,我认为这不是一个好的解决方案。 - 我想过在服务器上存储一个用户lastupdate键值对和每个对象的lastupdate ts,然后每当客户端联机并且ping新的更新时比较2。如果有更新,那么使用比上次用户更新ts更新的ts下载这些对象。 - 我也看到一些服务人员的提及,但我不熟悉它。 - 其他人选择昂贵的解决方案,只需在周期性的周期中进行全面更新,即每天,每4小时左右。

任何见解都会很棒。

回答

0

我在使用CouchDB(或相关技术(如Cloudant))的Offline First应用程序中使用的典型模式是执行所谓的one-database-per-user。基本思想是在注册应用程序时为每个用户分配一个CouchDB数据库。然后,只允许每个用户读/写该用户的CouchDB数据库。像帽衫或Cloudant特使工具(特使提供的一个数据库,每个用户的客户端“幻觉”),可以在这方面帮助:

这种方法适用适用于分割良好的用户数据的应用程序(例如个人TODO列表),并且出色地扩展出来。但是,当您想在用户之间共享数据(例如共享TODO列表)时,或者您想要在用户之间运行汇总数据分析时,该方法会带来挑战。

看来您的应用会落入此“用户之间的共享数据”类别。面临的挑战是,如何从用户数据库A获取共享数据到用户数据库B?在CouchDB中,这个共享数据将被表示为一个JSON文档。

一种体系结构是将消息队列与分配给每个用户数据库的发布者和订阅者代理一起使用。这些代理可以在服务器端运行,在您的安全策略中运行,以便谁可以访问哪些数据。这些代理将订阅其他用户数据库内的数据“通道”,并在另一侧发布数据的“通道”。这些通道可以由数据库中文档中包含的特定属性来定义。当代理检测到描述的事件时,它会运行过滤复制以将有问题的数据从一个用户数据库复制到另一个用户数据库。