3 ms·
Thanks! Convex looks neat, and you’re right, there is a lot going on at the data and data/frontend layer. Our approach is to provide a generic compute layer wit
by paulgb 5y ago
Thanks! Convex looks neat, and you’re right, there is a lot going on at the data and data/frontend layer. Our approach is to provide a generic compute layer with the session-lived backend model, so you can do more than just store data with it.
- ignoramous 5y agoSo, I presume, instead of a shared multi-tenant architecture convex), Spawner prefers per-user business-logic container + a per-user database container (+ any other module)? If so, once a user-session is adjudged to have been over, does Spawner snapshot them all to restore it whenever a session is to be resumed?
- paulgb 5y agoYou could run a database for each user inside Spawner, and there are use cases for that, like being able to run queries against arbitrary parquet files or materializing a sample of a larger dataset for fast queries. But in general if you just want to store program state, you would probably want to use Spawner for the compute and a multi-tenant database for persistence. We expect that Spawner will usually be part of a larger system that involves some multi-tenant components. Spawner doesn’t manage any persistence automatically, it’s up to the application. For some use cases, sessions are meant to be ephemeral (like a whiteboard session, or read-only data exploration), so there’s no state to persist at the end. For apps where there is state to persist, one option is desktop-style auto-save. By that I mean that the ground truth document state is in-memory, but every change to it triggers an asynchronous write to a persistent store. This is preferable to one-shot persistence at the end of the session for the same reason as it is on desktop apps: if there’s a power outage or hardware failure, you only lose a few seconds of work.