How to use convex in a big team/monorepo
Let’s say I’ve got a relatively large project with my team of let’s say 15 devs. This project consists of multiple frontend apps and multiple “services”. The model I’ve been working with for some time is an NX integrated monorepo (ie shared package.json) with NestJs micro services (graphql or grpc). Chuck pulumi or sst in there to deploy each deploy target.
Now the upside of this model is that you can establish unique deployment targets for each service and frontend, seperate databases by concern/domain and scale each part of the project independently. With local development you can have each developer using local db instances to test new schemas in isolation (ie not impacting the work of other devs).
The downside of this model is that wire up is incredibly cumbersome and time consuming, the number of integrations needed to support realtime, file storage etc.. is time consuming, and get full end to end type safety is nothing short of a burden.
I can see convex solving a heck of a lot of these integration and type safety problems, however it is unclear how convex is supposed to scale out as a developer experience with multiple devs working on a project at once?
Firstly, having a single “dev” environment - do all developers working locally use this one environment? How do they not step on each other’s toes with schema changes?
Second - is it possible to have multiple (neatly managed) convex instances acting as separated concerns in the one project?
Third - deployment to a personal environment for testing / PRs and spinning up a local environment just for the one developer before push to dev, staging and then prod?
I’d love to start using convex on some large scale stuff but it’s hard to get the team over the line without having clearer patterns recommended by the convex team.
Appreciate your feedback!
6 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
hi there!
so, yep. this is how convex works out of the box
each
npx convex dev spins up a private dev server for each engineer to iterate on independently
and then there is one prod server -- npx convex deploy
for a one-shot deployment to production vs. running a background autoreloading dev server on your private instanceThanks for the fast reply - ok that's pretty cool. In terms of having multiple convex instances is that a thing? Or can you suggest how to split up the convex folder/functions/schema for multiple domains - I'm really not a fan of having a single schema.ts file
Let's say we have several domains (e.g. org, billing, orders, templates etc..), each domain would have several tables, and subsets of functions
e.g.
org.team.workspaces.createWorkspace() - here the org (organisation domain) has a teams table, workspaces table, with a function to create a workspace for a team. Where as orders might be orders.fulfilment.getShipping() - has orders table, fulfilment table and shipping functions.. how best to organise something similar (in concept).here's a thread with the succinct info about structuring larger schemas: https://discord.com/channels/1019350475847499849/1135620048409591849/1135655304122618026
in short, you can define table definitions near the code that manages them, then import everything into your central
schema.ts file and use the ...modelSchema syntax to bring everything together
this is a pretty common pattern for code organization in medium sized projectin the future you'll be able to structure your project into multiple components ( https://www.convex.dev/components )... but we recommend waiting until your backend is at least 50-100k SLOC before taking that on. keeping it simple early is good
Components
Independent, modular, TypeScript building blocks for your backend.
I'd also note that ai town has by far the best example of breaking up a schema despite its schema being simple https://github.com/a16z-infra/ai-town . Unfortunately there is some structuring that ai-town has that i cant do due to my issues with mono repos but i just assume its a typescript skill issue.
GitHub
GitHub - a16z-infra/ai-town: A MIT-licensed, deployable starter kit...
A MIT-licensed, deployable starter kit for building and customizing your own version of AI town - a virtual town where AI characters live, chat and socialize. - a16z-infra/ai-town