Лучшая практика для синхронизации данных вкл/выкл с использованием AngularJS и Symfony 2

Я создаю относительно сложное и тяжелое веб-приложение с данными в AngularJS. Я планирую использовать php как бэкэнд RESTful (с symfony2 и FOSRESTbundle). Я потратил несколько недель на поиски различных решений для решений синхронизации вкл/выкл и, похоже, много решений (см. Список ниже для некоторых примеров). Но не из них, похоже, идеально подходят для моей ситуации. Как мне решить, какую стратегию меня устраивает?

Какие проблемы, которые могут определять "лучшие практики" для построения системы синхронизации вкл/выкл в AngularJS и symfony 2, требуют определенных исследований, но, во-первых, я хочу рассмотреть такие вещи, как скорость, простота внедрения, будущее (долговременное решение), расширяемость, использование ресурсов/требования на стороне клиента, наличие нескольких автономных пользователей, редактирующих одни и те же данные, сколько и какие типы данных хранить.

Некоторые из моих требований, о которых я сейчас знаю, следующие:

  • Пользователи часто будут отключены, а затем синхронизируются (локально созданные) данные с базой данных
  • Несколько пользователей используют часть доступных для редактирования данных (необходимо учитывать потенциальные проблемы слияния).
  • Пользователь может одновременно регистрироваться на нескольких устройствах.
  • Предоставление большого количества данных для хранения в автономном режиме (до гигабайта)
  • Я, вероятно, хочу, чтобы пользователь мог решить, что он хочет хранить локально.
  • Даже если пользователь подключен к сети, я, вероятно, хочу, чтобы пользователь мог выбрать, использует ли он все (бэкэнд) данные или только то, что доступно локально.

Некоторые возможные примеры решений

  • PouchDB - интересные стратегии для синхронизации изменений из нескольких источников
  • Racer - Node lib для синхронизации в реальном времени, на основе ShareJS
  • Meteor - DDP и стратегии для синхронизации
  • ShareJS - Node.js операционная трансформация, вдохновленная Google Wave
  • Restangular - альтернатива $resource
  • EmberData - EmberJSs ORM-подобная библиотека сохранения данных
  • ServiceWorker
  • IndexedDB Polyfill - Polyfill IndexedDB с браузерами, поддерживающими WebSQL (Safari)
  • BreezeJS
  • JayData​​li >
  • Loopbacks ORM
  • ActiveRecord
  • Модели BackBone
  • lawnchair - Легкая клиентская DB-библиотека от Brian Leroux
  • TogetherJS - библиотека синхронизации/совместной работы с несколькими клиентом Mozilla Labs.
  • localForage - библиотека улучшения Mozilla DOMStorage.
  • Orbit.js - библиотека синхронизации содержимого

(https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit#heading=h.864mpiz510wz)

Любая помощь будет высоко оценена:)

ОТВЕТЫ

Ответ 1

Кажется, вы хотите много чего, материал синхронизации сложный... У меня есть решение для некоторых из этих вещей в библиотеке OSS, которую я разрабатываю. Идея состоит в том, что он выполняет управление версиями локальных данных, поэтому вы можете выяснить, что изменилось и, следовательно, сделать значимую синхронизацию, которая также включает разрешение конфликтов и т.д. Это своего рода автономный метеорит, поскольку он действительно настроен на автономное использование (для Лондонское метро, ​​где у нас нет сигналов мобильной передачи данных).

Я также разработал экологическую систему, которая включает в себя диспетчер соединений и сервер. Основной проект находится в https://github.com/forbesmyester/SyncIt и очень хорошо документирован и протестирован. Приложение для тестирования экосистемы будет https://github.com/forbesmyester/SyncItTodoMvc, но мне еще нужно написать практически любые документы для него.

В настоящее время он использует LocalStorage, но будет легко перемещаться в localForage, поскольку на самом деле он использует обертку вокруг localStorage, чтобы сделать ее асинхронным API... Возможно, еще один список?

Ответ 2

Чтобы работать в автономном режиме с вашими запросами, я предлагаю разделить проблему на два сценария: контент (html, js, css) и данные (API REST).

Содержимое

Будет сохранен в автономном режиме appcache для небольших приложений или для расширенных случаев с удивительным serviceworkers. Chrome 40 +.

Данные

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

Внешний интерфейс

Храните ресурс и тень (используя, например, url как ключ) в localstorage для небольших приложений или в более продвинутые альтернативы (pouchdb, indexdb,...). С помощью ресурса вы можете работать в автономном режиме и при необходимости синхронизировать с сервером jsonpath, чтобы получить разницу между теневым ресурсом и отправить его на сервер. Запрос PATCH.

Backend

В бэкэнд учитывайте хранение теневых копий в redis.

Обе стороны (Frontend/Backend) должны идентифицировать клиента node, чтобы вы могли использовать x- syn-token в HTTP-заголовке (отправить его во весь запрос клиента с помощью перехватчиков angular).

Ответ 3

https://www.firebase.com/ он надежный и проверенный, и может использоваться в качестве бэкэнд-библиотеки и синхронизации для того, что вам нужно. но он стоит и требует некоторого интеграционного кодирования.
https://goinstant.com/ также является хорошим вариантом размещения.

В некоторых моих приложениях я предпочитаю использовать оба: syncing db source И еще одну основную базу данных. (mogno/express, php/mysql и т.д.). то каждый db обрабатывает то, что лучше всего, и он имеет функции (в режиме реального времени и безопасности и т.д.). Это верно независимо от поставщика sync-db (будь то Racer или Firebase или GoInstant...)

Ответ 4

Приложение, которое я разрабатываю, имеет множество одинаковых требований и строится в AngularJS. Что касается будущей проверки, есть две основные проблемы, которые я обнаружил, одна из них - попытки взлома, требующие шифрования и возможного использования одного тайм-ключа и бэкэнд-менеджера ключей, а другая поддержка WebSQL, отбрасываемого консорциумом стандартов, предпочтительнее indesedDB. Таким образом, поиск слоя абстракции, который может поддерживать оба, важен. Набор решений, который я придумал, довольно прямолинейный. Если автономные данные загружаются сначала в пользовательский интерфейс, и запрос отправляется на сервер REST, если он находится в онлайн-состоянии. Что касается разрешения конфликтов данных в многопользовательской среде, это становится решением бизнес-правила. Мое решение состояло в том, чтобы упростить этот вопрос и не вникать в слияние данных, но использовать сравнение штампов микрочести, чтобы определить, какая версия должна храниться и выталкиваться клиентам. Когда вы находитесь в автономном режиме, храните данные в виде грязной записи и нажатия на сервер при возврате в онлайн-состояние.

Или используйте ydn-db, который я сейчас оцениваю, поскольку он встроен в поддержку встроенного хранилища облаков AWS и Google.

Ответ 5

Другое предложение: Yjs использует OT-подобный алгоритм для совместного использования широкого диапазона поддерживаемых типов данных, и у вас есть возможность хранить общие данные в IndexedDB (так он доступен для автономного редактирования).