I’ve been wrapping my head around production migration strategy for a while now since I started using MongoDb Realm Sync - now Atlas Device SDK.
The documentation offers one and only one solution: migrate-schema-partner-collection
This article also only refer to partner collection: realm-schema-migration
While partner collection is a sound strategy for less frequent updates, it would be a nightmare to maintain for regularly and frequent updates. Imagine pushing out new features on a monthly basis, and imagine those features require breaking changes to existing schema. So in a year there will be 12 partner collections to keep in sync.
The documentation needs to be updated to include other alternative approaches to schema migration. Below are some strategies to mitigate breaking changes.
Feature Flag
Implement a feature flag to control the exposure of the new features and breaking schema changes. If a feature is flagged as a breaking change, the user should be prompted to update the client. The client update will cause the client schema to be in sync with the server.
Where should the feature flag be stored for all versions of the app? Outside the synced realm using something like the Atlas data api or server function. This is because the realm will not work to begin with if there is a breaking change, so the flag to signify the breaking change cannot be part of the synced environment.
Graceful degredation
Design the app to gracefully degrade when users haven’t updated the app. That is, design the schema such that there is a set of core collections that cannot undergo breaking changes throughout the life of the app. So the core functionality/features will always work regardless of the app’s version and schema. If the user refuse to update, they will always be using this core features only.
Migration caveats
Regardless of the strategy used to mitigate breaking changes, there’s a few caveat:
- What if the user declines to update the client app?
- Users will update the app at different time, so there needs to be a support period during the update.
To address these caveats and migrate gracefully, partner collections should be created with a support and time to live period:
- The support time signifies the graceful support period for the user who declines to update the app before it stops working for them. At the end of the support period, users are prevented from using the app until they update it.
- The time to live signfies the time the partner collection will expire and can be decommissioned. This should be longer than the support time to give users the grace period to update the app. If the user does not update the app during this time, it may result in the loss of data that is not synced.
- Each write will update all partnered collections for the duration of these grace periods until they are decommissioned.
What are your thoughts? And what are you currently doing to support breaking changes in your production applications? Please share your strategy here. I would really appreciate it. Thank you.