CODEWITHSUNDEEP
databasefirebasedatabase-migrationfirebase-realtime-database
eikooc
eikooc

Reputation: 2578

Database schema update in production

I have an app installed on mobile phones where users read and write to a Firebase database. I want to do a database schema change from:

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

to the following where ​a​ and ​b​ were merged into one:

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

While keeping the app functioning on both clients that have not upgraded to the new version with the new schema structure and clients that have upgraded.

The problem is keeping the two schema consistent and updated, while deploying the new app version as we cannot be sure people have updated the app.

In Firebase is this possible as there is no server to handle that? As in does Firebase have any functionality to listen to write events and then duplicating that data to other places, or what are my options?

Upvotes: 13

Views: 3067

Answers (2)

Mick F
Mick F

Reputation: 7439

Another solution with pros & cons:

  1. Let your database store what versions of your app are compatible with the current schema
  2. First thing when your app is launched, query this information in the DB
  3. If user A has a compatible version, congrats!
  4. If user B has not a compatible version, invite him to update his app, which could suck for him:
    • Maybe he's not able to update the app for technical reasons (for instance, for an iOS app, you increased your deployment target to an iOS version that is not compatible with this user's device)
    • Maybe he won't be able to update the app for a while because he's having poor network reception, etc.

I think maintaining several versions of the DB on Firebase is kind of an overkill, especially if your app is somewhat social and all versions should keep being functional. If version 1.0 creates content that should be accessible to version 2.0 and 3.0, and if you repeat this constraint to all other combinations of versions, uuugh, it's going to be a pain to maintain.

I think that's one major drawback using Mobile backend as a service solutions compared to traditional backends where maintaining a legacy endpoint would be much easier.

Upvotes: 7

Kamalen
Kamalen

Reputation: 526

Your only choice, if you want to preserve functionality on both old and new version, is to support both versions :

  • Any data structure specific of a given user needing migration can be updated once by the new app version (detect if the old format still exist and write as new).

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

Firebase or not, you cannot be expected to support old versions of your app forever. If you decide to support up to X previous versions, you will need to keep X versions of your data structure in parallel (and all the added complexities in writes operations).

Upvotes: 7

Related Questions