Изменение модели данных firebase (в то время как несколько версий приложений находятся в производстве)

Каков наилучший способ изменить модель данных Firebase, когда у вас есть несколько версий вашего приложения iOS?

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

Связанный с производительностью пример проблемы:

В версии 1.0 я наивно сохранял все, что связано с сообщением в разделе "/posts/". Теперь в версии 2.0 я хочу принять рекомендацию Firebase и добавить конечную точку "/user-post", чтобы быстро перечислить все сообщения для данного пользователя.

Люди, использующие версию 1.0 приложения iOS, не записывают никаких данных в "/user-posts", поскольку эта конечная точка не использовалась. Поэтому люди, использующие версию 2.0, не видят сообщений, созданных людьми, использующими старую версию приложения.

В теории я мог бы создать сервер где-нибудь, который слушает изменения в '/post/' и добавляет их к '/user-posts'. Со временем это сложно поддерживать, хотя, если у вас много разных версий вашего приложения.

Новая функция Пример проблемы:

Предположим, что в версии 1.0 вашего мобильного приложения вы пишете новые сообщения в блоге на '/posts/'. Теперь в версии 2.0 вашего приложения вы вводите функцию "Команды", и все сообщения должны быть в "/team/team-id/posts".

Люди, не обновленные до версии 2.0, все равно будут писать в "/posts". Эти сообщения не будут видны людям, использующим версию 2.0, которые читают "/team/team-id/posts".

Я понимаю, что вы могли одновременно поддерживать обе конечные точки (и индексы/сообщения на основе идентификатора команды), но со временем это, похоже, сложно поддерживать.

Традиционные решения:

Если бы я использовал что-то вроде Django или Express, я бы делал миграцию базы данных, а затем обновлял конечные точки на стороне сервера для создания блогов.

Это приведет к изменениям в базе данных от клиентов. Я мог бы теоретически добавить уровень приложения-сервера в мою архитектуру с помощью Firebase, но это не похоже на то, что рекомендуется: https://firebase.googleblog.com/2013/03/where-does-firebase-fit-in-your-app.html

Ответ 1

Я предлагаю вам использовать Firebase Remote Config для отображения оповещения через UIAlertController или другого экрана, если обновление доступно. Вы можете заставить пользователя обновить текущую версию, и у вас нет проблем позже, потому что никакие сообщения со старым кодом не могут быть созданы.

Чтобы ответить на ваш вопрос: Я бы разработал другое приложение, добавив его в тот же проект Firebase, а затем пусть это приложение преобразует все старые данные в новую модель данных. Таким образом, вы сделали бы это один раз после выпуска новой версии, а старые пользовательские данные преобразуются в новую модель данных, и все работает плавно. У вас также может быть свойство типа databaseVersion для каждого объекта.

Чтобы предотвратить будущие проблемы, у вас может быть общее свойство с именем app-version в Firebase Realtime Database. Перед каждым сообщением приложение проверяет, существует ли более новая версия. Если пользователь не может добавить сообщение, но если есть более новая версия, вы можете показать сообщение/оповещение через UIAlertController