What about replacing Asyncify with Atomics and SharedArrayBuffer?

[rhashimoto]

UPDATE 5/7/23: AccessHandlePoolVFS uses OPFS for storage without Asyncify or Atomics/SharedArrayBuffer. It requires recent browser versions (Chrome 108+, Safari 16.4+, Firefox 111+) that support the latest OPFS access handle spec.

UPDATE 7/18/24: OPFSCoopSyncVFS is an alternative to AccessHandlePoolVFS that works with a synchronous build and allows multiple database connections, with the trade-off that it only supports queries on a single database file. Also, Chrome and Firefox are nearing the stable release of JavaScript Promise Integration (aka JSPI or stack switching), a replacement for Asyncify without its space penalty (performance currently appears roughly equivalent).

There are significant time and space penalties for using WebAssembly SQLite built with Asyncify, which allows SQLite to callback to asynchronous Javascript functions. This is why wa-sqlite provides both synchronous (without Asyncify) and asynchronous builds, so developers can avoid those penalties if they don't need to use asynchronous callbacks.

Asynchronous callbacks are especially useful for calling asynchronous APIs like IndexedDB or fetch. But @phiresky (sql.js-httpvfs) and @jlongster (absurd-sql) independently discovered a clever way to make synchronous calls to asynchronous APIs using Atomics and SharedArrayBuffer. It's pretty cool!

The main catch with these APIs (and why it took so long to get support in Safari again) is they are potentially exploitable by Spectre malware attacks, so they are only enabled on pages served with special COOP/COEP HTTP headers which also heavily restrict including content from a different origin. This may prevent integrating certain third-party features like federated sign-in (e.g. OAuth2) and ads right now.

Implementing a SQLite VFS or module using Atomics and SharedArrayBuffer based on the described methods should be straightforward with the wa-sqlite synchronous build and I would be excited to see it happen. I don't plan to do that myself, however - i.e. I don't plan to add a synchronous IndexedDB (or File System Access) VFS to this repo - at least until it can be made to work with federated sign-in.

The size of the WebAssembly for wa-sqlite is about 507 KB for the synchronous build and 1,032 KB for the Asyncify build, so roughly double the size. The speed penalty is harder to characterize because although the cost of unwinding and rewinding the stack for asynchronous calls is quite high, it may still be relatively small compared to the asynchronous function itself. For example, if you're making a 1500 ms asynchronous call to WebTorrent then you may not care if Asyncify adds another 5 ms (I made these numbers up just for illustration). In general, the slower your wa-sqlite storage medium, the less you should care about Asyncify performance...though you still might want to tune your page size to reduce both Asyncify and non-Asyncify overhead.

Those interested in synchronous WebAssembly filesystems should also track Emscripten's WasmFS which is in development.

[steida]

Can't be a federated sign-in delegated to a server or another domain? I don't know your requirements, but it looks like a one-time action.

[rhashimoto]

I don't know enough about OAuth2 to say that is impossible, but I assume a workaround is not trivial as people at WHATWG are trying to fix it. In addition for me personally, my current web app needs only static content hosting, so any solution requiring server logic is a big step I would be reluctant to take.

[steida]

As far I remember, FB API allowed doing a redirect to their server page with redirecting back to my app with some auth in a query. I always preferred that, because I don't line popups.

[quolpr]

As a workaround of COOP you can use jlongster/absurd-sql#17 (comment) . It's a bit hucky 🙂

[rhashimoto]

@quolpr Very clever! Not something I'd want to use unless I were desperate, but still a cool trick to keep in your back pocket.