Offline support feedback/request
Continuation off https://discord.com/channels/1019350475847499849/1374547016700395620/1377011133617016852
for realtime we are currently migrating from a yanky YJS setup that we use for a chat. the pro is is its simple, simple to add data and offline is simple. conns are hard to know what data there is what state that it is in. adding things like notification for @mentions is hard. its generaly just bad as you can imagine. @ian
8 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!
Some more questions in case there's something custom you could build quickly now until the sync engine is out:.
1. To confirm: you don't want to migrate at all until there's first-class offline support?
2. How much chat history is needed to be offline? E.g. if it's just whatever was last loaded when you visited the channel / therad, is that sufficient, vs. full sync? e.g. how Messages / most mobile apps do it?
- If you reload the page and don't scroll back as far this time, is it ok to not have loaded all the data you used to have?
3. Is reloading the full history frequently ok? If not, how would you want to handle when the data format changes, e.g. the endpoint starts returning more data / new fields? Explicit versioning or SWR-style background things, with backwards-compatible UI?
4. Is there any security consideration here - e.g. explicitly clearing the cache on logout / token expiration, not storing in plaintext, or not any local persistence for public computers / etc.?
1. I'm open to migrating earlier, but I’d like to understand the timeline for offline support. Are you thinking in terms of weeks or more like a year?
2. I want to load the entire chat history since the chat is more of a secondary feature and is relatively short—probably around 30 messages max.
3. Reloading the full history is fine for now. It’s a web app, so just an indicator to the user saying to refresh. to get the latest updates.
4. I haven’t thought deeply about the logout behavior yet, but clearing the cache on logout seems reasonable. It's not a blocker for me. I’d be interested to hear your plans around security.
I'm also evaluating other alternatives, such as https://zero.rocicorp.dev/. I'd love to hear more about your implementation plans and how they compare to zero.
Zero Docs
The official documentation for Zero by Rocicorp.
Have you considered a simple brute-force approach, like making a
useCachedMessages hook? e.g.:
1. When loaded, does a usePaginatedQuery on your query that supports pagination
2. keeps calling loadMore until it's done
3. Writes to localStorage every time results updates
4. Defaults to localStorage when the status is LoadingFirstPage
This would allow you to have more control over how it's cached, when to invalidate, etc. And since they're all live subscriptions, changes to any message will cause an update & localStorage sync. I think a lot of the complexity of sync comes when you're trying to do offline writes, or only sync deltas. Doing usecase-specific offline caching is often simplified greatly by knowing your own constraints & requirements.Yeah, I guess this approach could work. I should clarify though saying it’s just “30 messages” was a bit misleading. It’s a collaborative document editor, so while individual chat threads are short, there are many of them so i think i need index db as 5meg can be a little limiting. I initially thaugh “chat history” in the context of UI performance, but my goal is broader I want everything to be available offline not just the chat, but also user info, team membership, etc. So I’m really looking for a general system for offline support, not just this single use case specific case.
Can you share how you plan to do offline support with convex? do you plan to support both offline writes and reeds?
There isn't a finalized proposal right now, but it's someone's primary project to get there, for transparency.
Offline writes are unlikely to be fully powered, but client-side ID generation is on the table.
fwiw, Zero gave up on offline writes recently from what I hear.
But having a good optimistic update + the existing pending mutation queue gets you pretty far (did you know mutations sent offline will continue to be retried until it's online for up to a week with exactly-once delivery when it does? that's in-memory though, so doesn't survive refresh (but there's a browser warning for that))
And there may be a richer offline write plan that I haven't seen yet
Thanks for all the help and info!
I don't think zero gave up on offline writes. But I agree its a hugely different beast to tame than "just" offline read
