Firebase - How to handle firestore & API changes in previous app versions

Viewed 615

I am using Firebase in an app which we deployed a couple of months ago. Of course, a few database changes happened and a lot of new triggers were created, which we now want to deploy to production together with a new app version.

The question is how do we force the previous app version to work with the new triggers and database structure without forcing our users to update the old app? Does anyone have any experience or suggestions in implementing this smoothly?

Some examples of what did change:

  • A counter to keep track of like counts was set in the app code in the previous version. This now has been moved to a cloud function.

  • A collection named '/users' is now split in two collections '/users' and '/_users', with '/users' containing all data accessible for all users and '/_users' containing all data only accessible for admins. Also a trigger is built to keep corresponding fields synchronized (fe. the field firstName occurs in '/users' and '/_users') So when a new user is created in the previous app version, the document will contain too many fields, because some belong to the '/_users' collection now. How can this be handled?

I've found out that with remote config we'll be able to force the users to update the app, but still that ain't the way to go for us. The first scenario seems easy to counter by just recalculating the count in the trigger. The second seems a little more complex.

0 Answers
Related