nickchomey
commented
4 months ago @tobiemh thanks for your attention in the AMA. I forgot that I had already created this issue previously. I just updated it with some more info.
I'm sure this is not a top priority, but surely is worth at least taking into consideration. After all, you added support for the various backends - and are creating your own - for a reason!
Is your feature request related to a problem?
Indexeddb is known to be slow and limited. And, when surreal is an abstraction on top of it, it has to go through many levels of abstractions - surreal.wasm > js > indexeddb > leveldb/sqlite.
(see here for info about how chromium currently uses leveldb - which rocksdb evolved out of - as the backing store for indexeddb, but are changing it to sqlite https://issues.chromium.org/issues/40253999)
Describe the solution
The Origin Private File System (OPFS) is a new-ish browser api that allows for high performance file system access. https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
It has support of all major browsers (look at the opfs-specific footnotes) https://caniuse.com/native-filesystem-api
A high profile example of it being used is SQLite Wasm, which seemingly allows for full sqlite usage in the browser. https://developer.chrome.com/blog/sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system/
Presumably surreal's rocksdb, speedb, and tikv backends could be used in a similar manner, which would surely simplify and improve performance for your wasm efforts. Likewise surrealkv when that is ready.
Alternative methods
SQLite wasm is getting a lot of attention and would probably be the easiest and most stable option. But it doesn't appear that Surreal uses SQLite as a storage backend, so there's probably no point in looking into it.
SurrealDB version
N/a
Contact Details
Reply to this issue
Is there an existing issue for this?
Code of Conduct