Multiple monorepo app deployments using the same convex backend?
What is the general consensus about this in production? If its doable then what are the possible downsides?
Assuming we have several apps deployed all using the same backend, i'm worried if one deploy fails while the other builds and updates the database the version mismatch. We do plan to track code versions and db versions eventually anyway which could have safeguards.
8 Replies
I dont think Convex has skew protection yet.
I would extend the suggested deploy process https://docs.convex.dev/production/hosting/vercel#how-it-works which first builds the application and then, only if that succeeds, deploys the Convex functions.
You could built all of the applications and only if that succeeds deploy the Convex functions.
Using Convex with Vercel | Convex Developer Hub
Host your frontend on Vercel and your backend on Convex.
Just to add to this, would this work if you are using something like Expo/react-native
@wild-silent In mobile applications, in any breakdown change on the backend side, you must first publish the application and then publish the backend. (Convex or any backend) In such scenarios, you should add the forced update logic to your application. When the user application is first opened, you can check the application version from the backend and show the forced update screen accordingly. We use this scenario in the company we work with.
Thanks @hasanaktasTR
Quick question: What happens with users on older versions of the app? The endpoints will probably not longer exist that the frontend (app) is trying to reach or the input has changed. Should I just force my users to do the update and dont let them use the app or is there another way?
@FleetAdmiralJakob 🗕 🗗 🗙
1) You can keep the current app version in your database and serve it with an API end. (You can keep it separately for iOS, Android and Web.)
2) If a change is made that will break the app, you should publish the app (web or mobile) first.
3) Then, you should publish the backend.
4) You should upgrade the app version in your database to the version you published.
5) If the version installed on the user's phone does not match the version coming from the API when the mobile app is opened or according to your scenario, you can show the forced update screen.
If your backend does not contain any breaking changes, you do not need to force the user to update. You can publish the backend directly.
These scenarios are valid for any backend in general, not just for convex,
In short,
Have an API that will not change and query whether it can be forcefully updated through this API.
Yeah all this i haven't really had enough thought into.
And there is probably several ways to automate most of it.
We have the example of how convex shows a new app available with the vercel api, but i guess they just log you out if its a breaking change?
I'm thinking some version check close to the global rate limiter so all mutations can be blocked if a mismatch happens.