how to manage larger convex codebase
Initially my Convex codebase was small and beautiful. Then the codebase grew and grew.
I tried to split the functions by table like
but it's not ideal, now that I have 27 tables.
I have checked out (https://github.com/a16z-infra/ai-town/blob/main/convex/schema.ts) which is a good reference point. are there more good references which showcases how to structure larger Convex codebase?
GitHub
ai-town/convex/schema.ts at main · a16z-infra/ai-town
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
5 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!
I am also considering using
effect-ts
which might help me compose the code more neatly with its services and layers.My pattern for scalable Convex code optimizes for fast iterations on feature code by separating out an "api layer" for feature code and a "db layer" that handles all actual data access. Bit more info on it here: https://discord.com/channels/1019350475847499849/1019350478817079338/1393251680618942585
Thanks for this. kinda reminds me of controller-service-repository pattern. (this is known as MVC pattern right?) very helpful
model view controller? kind of in that sense that there's a separation of concerns, I guess api layer could be the "controller". But it isn't intentionally mvc - more like using conventions to construct a sort of orm. The only goal here is providing assurance to yourself that authorization is dependable and data integrity won't be compromised, without having to slow down and think about those things during feature development.