4 ms·

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

samwillis 3y ago
So far the official WASM support from the SQLite project have only targeted WASM in the browser with a JS API. If I follow correctly this is about working with the SQLite team to upstream WASI support, which will eventually enable official support for it, and hence WASM on the server/cloud/edge and other WASI complement runners.
- ridruejo 3y ago
  Correct!
- sgbeal 3y ago
  > If I follow correctly this is about working with the SQLite team to upstream WASI support, which will eventually enable official support for it, and hence WASM on the server/cloud/edge and other WASI complement runners. (sqlite team's Wasm/JS guy here) That's the long and the short if it. We currently _actively_ target browsers only because our team has exceedingly limited bandwidth and has to be choosy with regards to where our dev time goes. Long-term, we intend to target all wasm platforms, but getting there is an ongoing process.
cfn 3y ago
The file of my desktop app is a SQLite db in disguise, I could use this to open these files in a web version of my app, I suppose. I know there is a javascript implementation of SQLite out there but maybe this has better performance.
jraph 3y ago
Apparently they use it for their tests. > We wanted to contribute upstream our patches for SQLite, as we were heavily relying on libsqlite for our tests of PHP.wasm with WordPress and Drupal.
rcarmo 3y ago
Well, you can use it to access SQLite files in WASM runners, of course. So you get a portable, platform-independent piece of code that can run anywhere. Although it was a bit of a surprise to see that they started out with the toy CLI tool that my self and Nicholas hacked on for a weekend (I wanted to be able to run SQLite commands in a-Shell, which is an excellent iPad CLI environment).
fastball 3y ago
The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in a desktop/mobile/edge/etc environment. You could also think of it as an attempt to turn WebAssembly into a fully-fledged JVM alternative. Compile once, run anywhere (including browser). For this specifically, it means that SQLite can integrate with WASI APIs (instead of only Web APIs as before) so that an SQLite Wasm build can run in other contexts besides browsers.
- aargh_aargh 3y ago
  What I don't get specifically is what's being implemented here with SQLite. Assuming WASI is an interface an application can call into for things like filesystem access, sockets, does this add SQLite as interface (analogously to sqlite.h) next to these as part of WASI? So SQLite will be "under" the interface, i.e. part of a standard runtime? How much "batteries included" is this runtime (planned to be)? If I understood this correctly, then there would be a tradeoff with having more batteries included which would imply more functionality for applications but make porting to new targets more work.
  - angelmm 3y ago
    The main work behind this patch is to ensure that SQLite can compile to Wasm32-wasi. WASI doesn't offer all syscalls that SQLite may require, so it may require some conditional definitions and code to ensure it works properly. It doesn't mean that SQLite is part of WASI, but you can embed SQLite in a Wasm32-wasi module. In the future, the WASI standard will include more and more features. This will allow SQLite to enable more internal features that are currently skipped due to the limitations on WASI.
    - aargh_aargh 3y ago
      Ah, so it's SQLite running on top of WASI, as a user (application, or rather library). Thanks for clearing that up for me.
angelmm 3y ago
(Wasm Labs team member here) SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module. This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these projects use Emscripten [4], but in the future the same Wasm32-wasi module will work. A teammate gave a lightning talk about SQLite and WASI at KubeCon EU [5]. In general, any environment that includes a wasm runtime can potentially run applications that uses SQLite under the hood. Before, it wasn't possible. - [1] https://wordpress.wasmlabs.dev/ https://wordpress.wasmlabs.dev/ - [2] https://developer.wordpress.org/playground/demo/ https://developer.wordpress.org/playground/demo/ - [3] https://wasmlabs.dev/articles/running-wordpress-with-mod-wasm/ https://wasmlabs.dev/articles/running-wordpress-with-mod-was... - [4] https://emscripten.org/ https://emscripten.org/ - [5] https://www.youtube.com/watch?v=E7tWtgf9V2s https://www.youtube.com/watch?v=E7tWtgf9V2s
- i2cmaster 3y ago
  I guess that's one way to prevent malicious plugins from destroying your site.
  - gzurl 3y ago
    Yes, exactly. We wrote an article here regarding PHP on Wasm that covers that: https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/ https://wasmlabs.dev/articles/mitigating-php-vulnerabilities...
  - candiodari 3y ago
    It does what WASM is meant to do: it allows extra functionality, such as a database, without exposing more surface area for exploits.
  - remram 3y ago
    They can still destroy your site, they just can't destroy anything else on the same server.

So far the official WASM support from the SQLite project have only targeted WASM in the browser with a JS API. If I follow correctly this is about working with the SQLite team to upstream WASI support, which will eventually enable official support for it, and hence WASM on the server/cloud/edge and other WASI complement runners.

ridruejo 3y ago
Correct!
sgbeal 3y ago
> If I follow correctly this is about working with the SQLite team to upstream WASI support, which will eventually enable official support for it, and hence WASM on the server/cloud/edge and other WASI complement runners. (sqlite team's Wasm/JS guy here) That's the long and the short if it. We currently _actively_ target browsers only because our team has exceedingly limited bandwidth and has to be choosy with regards to where our dev time goes. Long-term, we intend to target all wasm platforms, but getting there is an ongoing process.

cfn 3y ago

The file of my desktop app is a SQLite db in disguise, I could use this to open these files in a web version of my app, I suppose. I know there is a javascript implementation of SQLite out there but maybe this has better performance.

jraph 3y ago

Apparently they use it for their tests. > We wanted to contribute upstream our patches for SQLite, as we were heavily relying on libsqlite for our tests of PHP.wasm with WordPress and Drupal.

rcarmo 3y ago

Well, you can use it to access SQLite files in WASM runners, of course. So you get a portable, platform-independent piece of code that can run anywhere. Although it was a bit of a surprise to see that they started out with the toy CLI tool that my self and Nicholas hacked on for a weekend (I wanted to be able to run SQLite commands in a-Shell, which is an excellent iPad CLI environment).

fastball 3y ago

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in a desktop/mobile/edge/etc environment. You could also think of it as an attempt to turn WebAssembly into a fully-fledged JVM alternative. Compile once, run anywhere (including browser). For this specifically, it means that SQLite can integrate with WASI APIs (instead of only Web APIs as before) so that an SQLite Wasm build can run in other contexts besides browsers.

aargh_aargh 3y ago
What I don't get specifically is what's being implemented here with SQLite. Assuming WASI is an interface an application can call into for things like filesystem access, sockets, does this add SQLite as interface (analogously to sqlite.h) next to these as part of WASI? So SQLite will be "under" the interface, i.e. part of a standard runtime? How much "batteries included" is this runtime (planned to be)? If I understood this correctly, then there would be a tradeoff with having more batteries included which would imply more functionality for applications but make porting to new targets more work.
- angelmm 3y ago
  The main work behind this patch is to ensure that SQLite can compile to Wasm32-wasi. WASI doesn't offer all syscalls that SQLite may require, so it may require some conditional definitions and code to ensure it works properly. It doesn't mean that SQLite is part of WASI, but you can embed SQLite in a Wasm32-wasi module. In the future, the WASI standard will include more and more features. This will allow SQLite to enable more internal features that are currently skipped due to the limitations on WASI.
  - aargh_aargh 3y ago
    Ah, so it's SQLite running on top of WASI, as a user (application, or rather library). Thanks for clearing that up for me.

angelmm 3y ago

(Wasm Labs team member here) SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module. This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these projects use Emscripten [4], but in the future the same Wasm32-wasi module will work. A teammate gave a lightning talk about SQLite and WASI at KubeCon EU [5]. In general, any environment that includes a wasm runtime can potentially run applications that uses SQLite under the hood. Before, it wasn't possible. - [1] https://wordpress.wasmlabs.dev/ https://wordpress.wasmlabs.dev/ - [2] https://developer.wordpress.org/playground/demo/ https://developer.wordpress.org/playground/demo/ - [3] https://wasmlabs.dev/articles/running-wordpress-with-mod-wasm/ https://wasmlabs.dev/articles/running-wordpress-with-mod-was... - [4] https://emscripten.org/ https://emscripten.org/ - [5] https://www.youtube.com/watch?v=E7tWtgf9V2s https://www.youtube.com/watch?v=E7tWtgf9V2s

i2cmaster 3y ago
I guess that's one way to prevent malicious plugins from destroying your site.
- gzurl 3y ago
  Yes, exactly. We wrote an article here regarding PHP on Wasm that covers that: https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/ https://wasmlabs.dev/articles/mitigating-php-vulnerabilities...
- candiodari 3y ago
  It does what WASM is meant to do: it allows extra functionality, such as a database, without exposing more surface area for exploits.
- remram 3y ago
  They can still destroy your site, they just can't destroy anything else on the same server.