Updating the database schema in production

Question

I have an application installed on mobile phones where users read and write to the Firebase database. I want to change the database schema:

|-- "app" | |-- "a" | |--"y" | |-- "b" | |--"y" 

as follows, where a and b were combined into one:

 |-- "app" | |-- "x" | |--"y" 

Keeping the application running on both clients that have not been updated to the new version, with a new schema structure and updated clients.

The problem is reconciling and updating the two schemes when deploying the new version of the application, since we cannot be sure that people have updated the application.

In Firebase, this is possible, since there is no server to handle this? Like Firebase, are there any functions for listening to recording events and then duplicating this data in other places, or what are my options?

Answer 1

Your only choice, if you want to keep the functionality of both the old and the new version, is to support both versions:

• Any specific data structure for a given user in need of migration can be updated once by a new version of the application (to determine if the old format exists and write as new).

• If any structure has changed for global data used by all users, your database should store data in both the old and the new format. Being NoSQL, this should only cause write consistency issues (all locations need to be updated).

Firebase or not, you cannot be expected to support old versions of the application forever. If you decide to support up to X previous versions, you will need to store X-versions of your data structure in parallel (and all the added complexity of write operations).

Answer 2

Another solution with pros and cons:

• Let your database store which versions of your application are compatible with the current schema.
• First of all, when your application is running, request this information in DB
• If user A has a compatible version, congratulations!
• If user B does not have a compatible version, ask him to update his application, which may suck for him:
  • Perhaps he could not update the application for technical reasons (for example, for the iOS application, you increased the deployment target to an iOS version that is not compatible with this user device).
  • Perhaps he will not be able to update the application for a while, because he has poor network reception, etc.

I think that supporting several versions of the database on Firebase is a kind of bust, especially if your application is somewhat social, and all versions should remain functional. If version 1.0 creates content that should be available for versions 2.0 and 3.0, and if you repeat this restriction to all other combinations of versions, wow, this will be painful to support.

I think that one main drawback of using a mobile backend as a service solution is compared to traditional backends, where maintaining an outdated endpoint will be much easier.