Hello everyone,
I’d really appreciate, if someone having Meteor based backend for mobile app(s) in production, could share his experiences related to the system architecture evolution, i.e. version updates.
What I mean is, once you have a mobile app tightly connected to a backend(as generally is the case with Meteor monolith approach), how do you handle different versions of data/API on server and client? I.e. you have full control over server versioning, but you basically cannot influence how often a user updates his or her app, which can lead to version mismatch. Given that hot code push is not that reliable at all(in our experience), which mechanisms could be used in such a situation?
One possible solution would be to send client version to the API in each call and route the API call on server accordingly.
Link on any text about it or real life experience is highly appreciated.
We’ve got a pair of apps being used by around 10k users in a semi B2B setting,
We’ve found that HCP works extremely reliably apart from one caveat in iOS where changes to public files doesn’t trigger a HCP and instead triggers an incompatibilty.
A few things we did (or wish we had done):
Keep your app store versions upto date, so if something fails with HCP, users can download “close” to the latest version from the app store as a backup. Doing this also means new users won’t have to wait for a HCP. In general we submit builds once per week to the app stores, if there has been a HCP that week… This in itself is not trivial, as over the years Google/Apples minimum API versions have outpaced Meteor’s (Meteor still builds Swift 3, which is so out of date the latest XCode doesn’t even support migration).
Send the client version number to the server with every method call AND publication, trying to add this in later is hard, and with a rolling update, even if your HCP is close to immediate, it is possible to have clients and servers on slightly different versions.
Notify the user when the app is going to update, and force a refresh when it does. HCP doesn’t always trigger a refresh when it needs to, instead relying on the client closing and opening the app.
Similar to 3, if the HCP fails for whatever reason (e.g., cordova compat versions) notify the user that their app is out of date, and needs to be updated in the app store.
Audit any cordova plugin you plan to use, both the features AND the code - they’re not always well written, and we’ve had to swap out plugins in the past due to lack of maintenance/flaky feature support.
Consider setting your cordova compat versions manually from the start - doing so means you can set them to something short and meaningful, particularly useful if you have multiple apps. This also helps to allow you to swap out equivalent plugins, while continuing to be able to offer HCP for users with app versions using both the old and new version of a plugin (this also requires some careful coding around using the plugins from your code).
From the start we did 1, 3 and 4. We Started doing 5,6 about 6 months ago having had big problems with one of our plugins (one of the numerous FCM plugins), we wish we’d done 2 from the start, unfortunately it’s difficult to add now.