需要針對移動客戶端w共享對象的OfflineFirst客戶端緩存策略

Question

有誰知道OfflineFirst設計中客戶端緩存策略的聰明或標準解決方案嗎？

我有一個Ionic2（Angular2/TypeScript）客戶端，我試圖遵循OfflineFirst的原則，所以假設有一個不可預知的連接。我只想下載多個用戶共享的對象，以多對多關係形式存在，這些對象自上次客戶端更新以來發生了更改，並且僅在上次更新後才更新客戶端的本地存儲。

這裏是我目前的印象： - 任何推送策略似乎沒有意義，因爲首先離線？所以一些建議是使用Observable/Observer模式，但是這使用了Push策略，我認爲這不是一個好的解決方案。 - 我想過在服務器上存儲一個用戶lastupdate鍵值對和每個對象的lastupdate ts，然後每當客戶端聯機並且ping新的更新時比較2。如果有更新，那麼使用比上次用戶更新ts更新的ts下載這些對象。 - 我也看到一些服務人員的提及，但我不熟悉它。 - 其他人選擇昂貴的解決方案，只需在週期性的週期中進行全面更新，即每天，每4小時左右。

任何見解都會很棒。

Answer 1

我在使用CouchDB（或相關技術（如Cloudant））的Offline First應用程序中使用的典型模式是執行所謂的one-database-per-user。基本思想是在註冊應用程序時爲每個用戶分配一個CouchDB數據庫。然後，只允許每個用戶讀/寫該用戶的CouchDB數據庫。像帽衫或Cloudant特使工具（特使提供的一個數據庫，每個用戶的客戶端「幻覺」），可以在這方面幫助：

• http://hood.ie/
• https://github.com/cloudant-labs/envoy

這種方法適用適用於分割良好的用戶數據的應用程序（例如個人TODO列表），並且出色地擴展出來。但是，當您想在用戶之間共享數據（例如共享TODO列表）時，或者您想要在用戶之間運行彙總數據分析時，該方法會帶來挑戰。

看來您的應用會落入此「用戶之間的共享數據」類別。面臨的挑戰是，如何從用戶數據庫A獲取共享數據到用戶數據庫B？在CouchDB中，這個共享數據將被表示爲一個JSON文檔。

一種體系結構是將消息隊列與分配給每個用戶數據庫的發佈者和訂閱者代理一起使用。這些代理可以在服務器端運行，在您的安全策略中運行，以便誰可以訪問哪些數據。這些代理將訂閱其他用戶數據庫內的數據「通道」，並在另一側發佈數據的「通道」。這些通道可以由數據庫中文檔中包含的特定屬性來定義。當代理檢測到描述的事件時，它會運行過濾複製以將有問題的數據從一個用戶數據庫複製到另一個用戶數據庫。