Синхронизация основных данных с помощью Parse

Question

Я заинтересован в разработке библиотеки, которая будет синхронизировать базовую модель данных между устройствами через мобильный сервер Parse. Я хочу отразить функциональность, которую пытается обеспечить синхронизация данных ядра iCloud.

Почему бы не использовать iCloud или Ensembles? В настоящее время я использую синхронизацию данных ядра iCloud в производственном приложении, и это not working well for me. Я также хочу предоставить аутентификацию, независимую от Apple ID, что является еще одной причиной, по которой я хочу уйти от iCloud. Что касается Ensembles, я не уверен, будет ли это работать с Dropbox из-за deprecation of the dropbox sync API.

Я еще не начал разрабатывать библиотеку. Я ищу отзыв о своем плане, который излагается ниже. Эта конструкция основана на this SO answer.

Общей конструкция библиотеки:

1. Библиотека обеспечит стандартный базовый стек данных, которые бы создать сохраняющийся координатор магазина и контекст управляемого объекта. Все стандартные операции CRUD с данными ядра будут проходить через интерфейс, предоставляемый библиотекой.

2. Каждый раз, когда выполняется операция CUD, объект синхронизации будет сохранен в Parse в фоновом режиме, который включает всю информацию, необходимую для воспроизведения операции. Это включает в себя: тип операции, который имел место, уникальный идентификатор для объекта, на котором работал, и в случае операции создания будет предоставлен родительский объект и отношения.

3. Каждая операция будет иметь связанный с ней номер change_id. Каждый раз, когда устройство загружает и выполняет операцию, в нем будет храниться последняя переменная, связанная с этой операцией.
4. Перед загрузкой каждой операции синхронизации устройство отправит запрос на сервер, чтобы гарантировать, что номер измененного номера совпадает с сохраненным локально. Если change_id на сервере выше, он сначала загрузит все операции синхронизации и выполнит их, а затем загрузит свои собственные операции синхронизации.
5. Конфликты (два устройства, редактирующих одно и то же значение в автономном режиме), будут разрешены путем определения того, какое устройство изменило последнее значение.

Я ничего не теряю здесь? Каковы некоторые возможные проблемы с этим подходом? Я слышал, что синхронизация сложна, если этот тип обязательств остался до самых опытных разработчиков?

Answer 1

Я не самый предвзятый ответчик, потому что я разработчик рамки Ensembles, но позвольте мне изложить некоторые мысли.

Что касается самих ансамблей, это бэкэндно-агностический каркас. Да, он работает с iCloud и Dropbox Sync API, но также с CloudKit, API Dropbox Core (который не устарел) и WebDAV. Существует также собственный сервер Node.js, доступный с одним пакетом, который позволяет размещать данные самостоятельно с использованием Heroku и S3.

Так что, даже если вы не хотите придерживаться Apple, есть другие варианты. Но даже более того, вы можете написать свой собственный класс адаптера. Большинство из них составляют около 500 строк кода, и вы можете основывать их на одном из существующих классов. Это позволит вам создать бэкэнд, который хранит данные и аутентифицируется с помощью Parse, и оставьте объединение данных в Ensembles. Другим преимуществом этого является то, что вы можете легко перейти на другие серверы в будущем или предложить их в качестве опций. (CloudKit определенно стоит посмотреть.)

Но давайте предположим, что вы настроены не использовать чужую инфраструктуру, тогда да, ваш подход звучит глобально правильно.

Вместо того, чтобы делать операции CRUD через интерфейс, вы можете просто наблюдать NSManagedObjectContextDidSaveNotification и извлекать изменения из словаря userInfo.

Уверен, что вы найдете много мелочей, о которых не подумали, и именно эти детали, как правило, делают синхронизацию сложной. Один из таких примеров состоит в том, что вам нужно создать что-то достаточно прочное для обработки сбоев, таких как операции Parse, которые не выполняются до того, как приложение завершит работу. Вероятно, вам нужно иметь тег изменения для каждого объекта, поэтому вы можете получить те, которые были изменены с момента последней синхронизации.

Если ваше приложение имеет небольшой объем данных, то создание этой системы не является ужасно трудным, но по мере того, как ваши данные начинают увеличиваться, вам нужно начать использовать такие вещи, как пакетная обработка, чтобы поддерживать данные в памяти на iOS. Это может занять много времени. Например, Ensembles 2 имеет почти идентичный API для Ensembles 1, но я потратил около 4 месяцев, просто переписывая такие вещи, как пакетная обработка, чтобы быть эффективной с памятью.

Я построил прототип приложения, используя описанный вами подход (приложение было социальным, а не синхронизирующим, следовательно, не было ансамблей). Я использовал CloudKit, который очень похож на Parse. Это было около 1000 строк кода Swift, чтобы получить полную загрузку/загрузку данных в порядке, с локальным кэшем Core Data. Это, безусловно, полезно, особенно если вы хорошо знаете Core Data. В противном случае может быть кривая обучения.

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