Нужна стратегия кэширования клиентов с автономными файлами автономного доступа для мобильных клиентов w

102
12

Кто-нибудь знает умное или стандартное решение для политики кэширования клиента в дизайне OfflineFirst.

У меня есть клиент Ionic2 (Angular2/TypeScript), и я стараюсь следовать принципам OfflineFirst, поэтому предполагая наличие непредсказуемого соединения. Я хочу только загружать объекты, которые совместно используются несколькими пользователями, в отношении многих ко многим, которые изменились с момента последнего обновления клиента и обновили локальное хранилище клиента только с изменениями с момента последнего обновления.

Здесь мое текущее впечатление: - Любая стратегия push не имеет смысла, кажется, учитывая оффлайн в первую очередь? Поэтому некоторые предложения касались использования шаблона Observable/Observer, но для этого используется стратегия Push, которая, как я считаю, не является хорошим решением. - Я думал о сохранении пары ключ-значение user-lastupdate на сервере вместе с lastupdate ts для каждого объекта, а затем сравнивает 2 каждый раз, когда клиент приходит в сеть и пингует для новых обновлений. если есть обновления, загрузите те объекты с помощью ts, новее, чем последние обновления ts пользователя. - Я также видел некоторые упоминания об обслуживающих рабочих, но я не знаком с ним. - другие выбрали дорогостоящие решения, просто делая полное обновление на периодических пингах, то есть каждый день, каждые 4 часа или около того.

Любые идеи были бы замечательными.

спросил(а) 2017-08-11T21:40:00+03:00 2 года, 10 месяцев назад
1
Решение
67

Типичный образец, который я видел в приложениях Offline First, которые используют CouchDB (или связанные с ним технологии, такие как Cloudant), должен делать то, что называется one-database-per-user. Основная идея - назначить базу данных CouchDB каждому пользователю, когда они регистрируются для приложения. Затем разрешите каждому отдельному пользователю читать/записывать эту базу данных пользователя CouchDB. Такие инструменты, как Hoodie или Cloudant Envoy (Envoy предоставляет "иллюзию" клиента с одной базой данных для каждого пользователя), может помочь в этом:

Этот подход хорошо подходит для приложений с хорошо сегментированными пользовательскими данными (например, личный список TODO) и масштабируется на удивление хорошо. Этот подход представляет проблемы, однако, когда вы хотите обмениваться данными между пользователями (например, общим списком TODO) или хотите запустить аналитику по совокупным данным между пользователями.

Похоже, ваше приложение попадет в эту категорию "общие данные между пользователями". Задача состоит в том, как получить общие данные из базы данных пользователей A в пользовательскую базу данных B? В CouchDB говорят, что эти общие данные будут представлены как документ JSON.

Одна архитектура - использовать очередь сообщений с издателем и агентом абонента, назначенным каждой каждой пользовательской базе данных. Эти агенты будут работать на стороне сервера, в рамках ваших политик безопасности, у кого есть доступ к каким данным. Эти агенты будут подписываться на "каналы" данных в других пользовательских базах данных, а на оборотной стороне - на "каналы" данных. Эти каналы могут быть определены конкретными атрибутами, содержащимися в документах в базе данных. Когда агент обнаруживает событие, о котором идет речь, он выполняет отфильтрованную репликацию для копирования данных, о которых идет речь, из одной базы данных пользователя в другую.

ответил(а) 2017-08-15T00:50:00+03:00 2 года, 10 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема