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 text was updated successfully, but these errors were encountered:
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.
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.
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 text was updated successfully, but these errors were encountered: