3 ms·
> There is a project called "Absurd SQL" to back SQLite with a custom block based FS on top of IndexedDB. It is somewhat absurd but it works incredibly well! (
by sgbeal 4y ago
> There is a project called "Absurd SQL" to back SQLite with a custom block based FS on top of IndexedDB. It is somewhat absurd but it works incredibly well!
(The fiddle dev here...)
That is, AFAIK, the current state of the art for persisting sqlite wasm-side dbs. The JS-side APIs for providing such support are currently evolving within the browsers. With any luck, we'll have widespread JS-native persistent storage for sqlite within the next couple of/few years. (Those things take time to develop and, just as importantly, propagate through the browser ecosystem.)
> I think combining WASM SQLite with the session extension ... would be a super interesting way to build an eventually consistent datastore for web apps. You could do all transactions locally and sync back and fourth just the changes.
FWIW, that's what i personally envision will likely be the most compelling use case for the sqlite wasm builds. The fiddle app is _just_ the sqlite3 shell, not the sqlite3 library, but we've also created a plain-jane wasm binding of the C library and written an OO-style API on top of that (roughly akin to sql.js and friends, with different design decisions in some places). We're working on an API conceptually similar to sql.js's "worker" API, where the sqlite3 wasm can run in a WebWorker and the main thread can talk to it via WebWorker messages. That said, for the type of jobs sqlite will likely be doing in web clients, the workloads will be fast enough that running the wasm build in the main thread is unlikely to lead to any usability issues (blocked UI). Nobody's going to be using a 20gb db in such an app (because the browser won't let them) and sqlite is blazing fast for small data sets. Even so, the core APIs are agnostic of whether they're running in the UI thread or a WebWorker, so the client can decide for themselves how to plug it in.
- samwillis 4y ago> We're working on an API conceptually similar to sql.js's "worker" API Thats interesting, so it will be an "official" WASM JS binding for SQLite? Is it available anywhere? > With any luck, we'll have widespread JS-native persistent storage for sqlite within the next couple of/few years If you are building an "official" WASM JS binding have you considered doing something similar to absurd SQL in order to achieve atomic persistence?
- sgbeal 4y ago> Thats interesting, so it will be an "official" WASM JS binding for SQLite? That's not guaranteed/official yet but it has been discussed and seems to be where we're headed. In the end it's Richard's decision, though, not mine. (That said, i would like to see that happen but won't be soul-crushed if it doesn't because creating a wasm build of sqlite is _so easy_ to do that any project can create their own with little effort.) > Is it available anywhere? Source repo: https://sqlite.org/src https://sqlite.org/src It's currently in the sqlite3 trunk. After configuring the tree, run "make fiddle" or (cd ext/fiddle; make), though the latter approach requires GNU make, not some under-powered make-wannabe. (The top-level makefile is compatible with Lesser Makes.) Edit: it requires emscripten and ext/fiddle/index.md provides an overview of how to get it going. > If you are building an "official" WASM JS binding have you considered doing something similar to absurd SQL in order to achieve atomic persistence? Not until we have JS APIs which are built for that type of thing. Absurd's approach is an interesting proof of concept but is aptly named. Absurd is a stopgap measure which will, with any luck, "soon" be obsoleted by ... how to put this... "less absurd" alternatives ;).