Feature: Offline Capabilities

[itsezc]

Is your feature request related to a problem?

Currently its not clear on how to handle offline access. For PWA's and apps that require Offline compatibility it'd be great if we can have an "offline" mode availability to sync back when online.

Describe the solution

A local store to "cache" fetched data and mutate the fetched data, with additions made that are sync'ed when the database is available and stored under localStorage for persistence perhaps.

Alternative methods

This could be achieved using third party libraries such as react-query but this provides lock in and only available for certain frameworks.

SurrealDB version

2.0

JavaScript SDK version

latest

Contact Details

No response

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[nickchomey]

Is this not what surrealdb.wasm is for? It gives you, essentially, a full surrealdb instance in the browser. Though it doesn't have a syncing mechanism. And, as I've noted in various issues in that repo, the performance is brutal.

[itsezc]

Is this not what surrealdb.wasm is for? It gives you, essentially, a full surrealdb instance in the browser. Though it doesn't have a syncing mechanism. And, as I've noted in various issues in that repo, the performance is brutal.

Similar (atleast to my understanding), yes. However I don't want a full DB running on WASM for obvious reasons as you stated performance being one of them, but this issue is more focused on the "Sync" aspect when back online.

[LucyEgan]

While I like this, I'm not sure how well this can work for ws:rpc calls, unless your caching that you saw that exact rpc string before and return the previous response?

If its for the http:rpc calls then i would assume you can handle this via a service worker (I've not tried this with surreal, but off the top of my head)

Either way for storing this data it would probably be better under Cache and not localStorage

[nickchomey]

Is this not what surrealdb.wasm is for? It gives you, essentially, a full surrealdb instance in the browser. Though it doesn't have a syncing mechanism. And, as I've noted in various issues in that repo, the performance is brutal.

Similar (atleast to my understanding), yes. However I don't want a full DB running on WASM for obvious reasons as you stated performance being one of them, but this issue is more focused on the "Sync" aspect when Offline.

I'm not quite following. Sync and caching are very different things - caching just caches your queries to the backend. Sync sounds like something in the direction of CRDT, or at least some sort of replication.

What would be storing, manipulating, fetching etc the synced data in the browser, if not surrealdb.wasm? (Ps the wasm just provides the surrealdb "server", which sits on top of indexeddb or memory store, just like surreal has various storage backends on your server).

This doesn't sound feasible or desirable to me, as described. A cache, on the other hand (something like react-query) seems more possible

Ps this has been discussed here previously https://github.com/orgs/surrealdb/discussions/107

[itsezc]

Is this not what surrealdb.wasm is for? It gives you, essentially, a full surrealdb instance in the browser. Though it doesn't have a syncing mechanism. And, as I've noted in various issues in that repo, the performance is brutal.

Similar (atleast to my understanding), yes. However I don't want a full DB running on WASM for obvious reasons as you stated performance being one of them, but this issue is more focused on the "Sync" aspect when Offline.

I'm not quite following. Sync and caching are very different things - caching just caches your queries to the backend. Sync sounds like something in the direction of CRDT, or at least some sort of replication.

What would be storing, manipulating, fetching etc the synced data in the browser, if not surrealdb.wasm? (Ps the wasm just provides the surrealdb "server", which sits on top of indexeddb or memory store, just like surreal has various storage backends on your server).

This doesn't sound feasible or desirable to me, as described. A cache, on the other hand (something like react-query) seems more possible

Ps this has been discussed here previously https://github.com/orgs/surrealdb/discussions/107

My understanding of Caches (React Query) have been that querying & mutating are possible while offline - from a Cache; querying for data reliant on (locally stored) mutation objects is not easy / possible. Perhaps with SurrealDB WASM it would totally be possible but performance shouldn't be a bottleneck.

I see from the Discussion your using RxDB to more or else tackle the same issue I'm going through, I'm hoping such functionality becomes native to the SurrealDB JS library.

[nickchomey]

RxDB is lightyears ahead of everything else when it comes to in-browser databases. The free stuff is great, and the paid addons are even better.

I'd love to see similar capabilities come to Surreal, but hope that they'll stay focused on just getting the core DB and SDKs working well - there's still a ton of work to do on all of that.

[itsezc]

TanstackDB is viable option to integrate with via Collections, similar to the integrations of ElectriSQL and RxDB (as Caches0.

Potential Implementations for CRDTs:

• https://automerge.org/
• https://www.loro.dev/
• https://github.com/y-crdt/y-crdt (Yjs)
• https://github.com/josephg/diamond-types