Local first
The app that I'm building will eventually be required to use local first sync for offline use ability. My question is, I'm very early in the build phase, so I can easily bake in something like replicache, but would it be worth it to wait for Convex's native solution?
How much of a refactor is it expected to take when Convex's sync solution is released?
If it is low, I can justify waiting. If it's the same level effort as implementing replicache, I'd rather do that now before the amount of codes to be refactored is too large.
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!
Keep in mind I'm not too much worried about the timeline so much is the difficulty to implement once that time comes.
hey @fugufish, our plan is to make incremental adoption of local sync pretty easy: you'd be able to start with a vanilla convex app (that requires the server to be online) and then gradually move data fetching + optimistic updates to the object sync engine.
the general idea with our architecture is that you define sync tables (like electricsql's "views") that are backed by convex queries. here's an example from our linear clone prototype: https://github.com/get-convex/curvilinear/blob/main/convex/sync/issues.ts
so, you should be able to reuse a lot of your server side queries when porting the vanilla convex functions to this sync table API.
then, on the client, you'd change your UI components from calling server side query functions to querying the sync tables in the local store.
mutations stay exactly the same on the server but then have an optimistic update that patches the local store.
happy to go into more details if it'd be helpful, let me know! but the overall idea is that it shouldn't be too big of a lift to incrementally adopt over regular convex.
GitHub
curvilinear/convex/sync/issues.ts at main · get-convex/curvilinear
Contribute to get-convex/curvilinear development by creating an account on GitHub.
Very much looking forward to this. I’ve got some big ports I’m working on from MongoDB/Realm and the big blocker is offline. And September is the looming sunset for Realm…
@sujayakar Would it be crazy to mix convex with livestore? When you are offline use livestore and the mutation log, when you are back online update convex, check convex mutation log add changes. Not sure if you could use both providers in an app. Just an idea.
not at all! yeah convex as a mutation log makes a lot of sense
you could also have the server maintain a snapshot of the latest computed state -- you could update the snapshot once you push entries on to the log, or you could have a background job that periodically folds in batches of mutations into the snapshot
that way non-syncing views (e.g. a lightweight web page) can view the state without having the replay the log