Синхронизация основных данных через Parse

Question

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

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

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

Общий дизайн библиотеки:

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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