Подтвердить что ты не робот

Архитектура слоя данных, которая использует как localStorage, так и удаленный сервер REST

У кого-нибудь есть идеи или ссылки на то, как реализовать уровень сохранения данных, который использует как локальное хранилище, так и удаленное хранилище REST:

Данные определенного клиента хранятся в localStorage (с использованием адаптера с индексом db-данных). Локально сохраненные данные синхронизируются с удаленным сервером (с использованием RESTadapter на основе ember-данных).

Сервер собирает все данные от клиентов. Использование математических наборов обозначение:

Server = Client1 ∪ Client2 ∪ ... ∪ ClientN 

где, вообще говоря, любая запись может быть не уникальной для определенного клиента:

ClientX ∩ ClientY ≠ 0,  ∀ X,Y ∈ [1,N]

Вот несколько сценариев:

  • Клиент создает запись. Идентификатор записи не может быть установлен на клиенте, поскольку он может конфликтовать с записью, хранящейся на сервере. Поэтому вновь созданная запись должна быть привязана к серверу → получить идентификатор → создать запись в localStorage.

  • Запись обновляется на сервере, и, как следствие, данные в localStorage и на сервере выходят из строя. Только сервер знает об этом, поэтому архитектуре необходимо реализовать архитектуру push (?)

Не могли бы вы использовать 2 магазина (один для localStorage, один для REST) ​​и синхронизацию между ними, или использовать гибридный адаптер indexedDB/REST и записать код синхронизации внутри адаптера?

Вы можете увидеть какой-либо способ избежать внедрения push (Web Sockets,...)?

4b9b3361

Ответ 1

Проблема, которую вы вызываете, не может быть решена в нескольких параграфах или просто ответила. Тем не менее, вот моя попытка...

Во-первых, существует ряд трудностей с принятым вами подходом:

  • Клиенты всегда должны подключаться к сети для создания данных и получения ключей от сервера.
  • Если вы делаете разные магазины (localstorage и REST), весь код приложения, требующий данных, должен выглядеть в обоих магазинах. Это значительно увеличивает сложность каждой части приложения.
  • После создания строки, если вы хотите создать дочерние строки, вы должны дождаться, пока сервер вернет первичный ключ, прежде чем вы сможете ссылаться на него как на внешний ключ в дочерней строке. Для любых умеренно сложных структур данных это становится тяжелым бременем.
  • Когда сервер опускается, все клиенты не могут создавать данные.

Вот мой подход. Он использует SequelSphereDB, но большинство концепций можно использовать повторно в других системах управления данными клиентов.

FIRST: используйте UUID для первичных ключей.

Большинство систем управления данными клиентов должны обеспечивать способ генерации универсально уникальных идентификаторов. SequelSphere делает это просто с помощью функции SQL: UUID(). Наличие UUID в качестве первичного ключа для каждой строки позволяет первичным ключам генерировать на любом клиенте в любое время без необходимости связываться с сервером и при этом гарантировать, что идентификаторы будут уникальными. Это также, следовательно, позволяет приложению работать в автономном режиме, не требуя подключения к серверу во время выполнения. Это также заставляет сбитый сервер отключать всех клиентов.

SECOND: используйте один набор таблиц, которые отражают сервер.

Это скорее требование простоты, чем что-либо еще. Это также является требованием для следующих двух основополагающих принципов.

THIRD: для нисходящей синхронизации небольших наборов данных предпочтительнее обновлять данные клиента с сервера.

По возможности выполните полное обновление данных на клиенте с сервера. Это более простая парадигма и приводит к меньшему количеству проблем с целостностью данных. Основным недостатком является размер данных при передаче.

ЧЕТВЕРТЫЙ: для нисходящей синхронизации больших наборов данных выполните обновления Transactional

Здесь мой подход становится немного более сложным. Если набор данных слишком велик и требуется только синхронизировать измененные строки, вы должны найти способ их синхронизации в соответствии с "транзакциями". То есть: вставляет/обновляет/удаляет в том порядке, в котором они были выполнены на сервере, чтобы обеспечить простой script для выполнения на клиенте.

Предпочтительно иметь на сервере таблицу, на которой записываются транзакции, которые должны быть синхронизированы с устройством. Если это невозможно, заказ часто может быть записан на сервере с использованием меток времени в строках, а клиент запрашивает все изменения с определенной отметки времени. Big Negative: вам нужно будет отслеживать удаленные строки либо путем "логического" удаления, либо путем отслеживания их в своей таблице. Даже при этом изолирование сложности сервера предпочтительнее распространять его на всех клиентов.

FIFTH: для восходящей синхронизации используйте обновления Transactional

Здесь SequelSphereDB действительно светит: он будет отслеживать вас о всех вставках, обновлениях и удалениях, выполняемых против таблиц, а затем предоставлять их обратно во время синхронизации. Он даже делает это через перезапуск браузера, поскольку он сохраняет информацию в localstorage/indexeddb. Он даже обрабатывает фиксации и откаты соответственно. Клиентское приложение может взаимодействовать с данными, как обычно, без необходимости задумываться над записью изменений, а затем использовать SequelSphereDB "Change Trackers" для воспроизведения изменений во время синхронизации.

Если вы не используете SequelSphere (вы должны быть), сохраните на клиенте отдельную таблицу для записи всех вставок, обновлений и удалений, выполняемых клиентом. Всякий раз, когда клиентское приложение вставляет/обновляет/удаляет строки, сделайте копию этого в таблице "транзакция". При восходящем времени синхронизации отправьте их. На сервере просто выполните те же шаги в том же порядке, чтобы реплицировать данные, которые были на клиенте.

ТАКЖЕ ВАЖНО: всегда выполняйте синхронизацию вверх до полного обновления клиентских таблиц с сервера.:)

Заключение

Я предлагаю перейти на простоту по сложности в максимально возможное количество мест. Использование UUID для первичных ключей чрезвычайно полезно для этого. Использование каких-то "трекеров изменений" также очень полезно. Использование такого инструмента, как SequelSphereDB для отслеживания изменений для вас, является наиболее полезным, но не необходимым для этого подхода.

ПОЛНОЕ РАСКРЫТИЕ: Я тесно связан с компанией SequelSphere, но этот продукт действительно не нужен для реализации вышеуказанного подхода.