Architecture, microservices, offline support
Any support for triggers, subscriptions or events as of now, allowing more flexible microservice setups? Simply creating small services that responds to some added row or similar to update some value on it.
It would be great to hear some more of what is on the roadmap and what the current shortcomings for some types of architectures are as you guys see it, and potentially how you would currently architect systems for specific needs. How do you see the current strengths now, and where do you see Convex going. It doesn't have to be complex, but just seeing a bunch of flowcharts with this is how things can be put together goes a long way towards building a mental model and seeing how you guys think about different setups. Hasura is great at communicating how they think, even tho I would prefer to not touch another GraphQL schema ever again.
I'm a big fan of rethinking how the regular state architecture should be done, and hate databases enough that I would prefer a giant ball of magic hierarchical reactive CRDT at times.
Some articles, systems and new approaches to things I think are great for sparking discussions. Especially the two first.
https://riffle.systems/essays/prelude/
https://3factor.app/
https://hasura.io/blog/how-hasura-works/
https://rxdb.info/
https://syncedstore.org/docs/
https://www.effect.website/
1 Reply
@Jamie replied here about the backend architecture (triggers, workflows):
https://discord.com/channels/1019350475847499849/1142479852885246102
I’d add that we’re probably closer to monolith architectures than micro services - your whole backend gets deployed at the same time, and this enables transactional guarantees about state of data in the system and in the database (and schema). Personally, coming from FB, I think this approach, with appropriate tooling, can scale to arbitrarily sized projects.
The latter projects linked here are more about managing and persisting state on the client. For now our approach is to embrace the dependency on a server and let the server resolve conflicts (in whichever way is appropriate for given application).