Architecture of larger convex apps.
Hey guys, I'm a solo developer working with Convex and some of my apps are getting bigger with complex business logic. I wanted a cleaner architecture approach but don't want to over-engineer since I'm working solo.
I asked Claude for suggesting and it gave me the ones in the image, but I'm not experienced enough to tell if they are good or not.
Would love to hear from seasoned devs about:
Have you used any of these patterns with Convex?
Which approach would you recommend?
Any pitfalls to watch out for?
7 Replies
One pattern we've seen larger codebases use is splitting up the schema into smaller pieces, and using "accessor" functions to access it
These images don't mean much to me
What are the pain you're you're hitting? Maybe they can be addressed directly or the right pattern will be informed by what's a pain now.
Do you have examples of this “accessor” patterns?
Not handy, what would help to see? What types of programming are you familiar with?
Accessor means getters and setters generally, here I more mean CRUD. If you have an organizations table, keep addMemberToOrg, getAllOrgMembers, etc. in one file or directory. Don't directly insert into the organizations table from outside of that directory, so you don't have to remember to check permissions or set foreign keys or enforce constraints from other places.
Mostly write helper functions. API endpoints (like mutation(() => { ... })) should be short mostly call helper functions and might not belong in the organizations folder at all.
Have you used Rails or Django? Think the class methods on the model classes.
Thanks for the response! i’ve only used jsx based frameworks (JavaScript) and i understand what you’re getting at.
Most of my queries and mutations just call helpers as you say.
Im struggling to visualise what your get here though
“If you have an organizations table, keep addMemberToOrg, getAllOrgMembers, etc. in one file or directory. Don't directly insert into the organizations table from outside of that directory, so you don't have to remember to check permissions or set foreign keys or enforce constraints from other places.“
The idea is to have only set of ways to modify a logical entity. If you need to split the user created in addUser() into three separate tables, you'd like to have only one file if functions to change instead of feeling the codebase for everywhere the users table is accessed.
Oh this makes sense! Thanks
The best example of splitting up a schema is convex ai-town https://github.com/a16z-infra/ai-town/blob/main/convex/schema.ts
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