Just-in-time code-generation is a useful tool for programming languages and various other use-cases which require more dynamic execution. However, the security model of WebAssembly ensures that the module memory is not addressable at runtime, you can’t just generate wasm code then ‘jump’ to that memory location.
This quite technical article explores ‘late linking’, where new WebAssembly modules are generated at runtime, and invoked via
It is much easier to learn a new technology if you can just pick it aup and get started without needing to download, install, configure and all that annoying nonsense. This is why so many technologies have som form of online playground. This is a challenge for server-side technologies, such as databases - they still need deploying, configuring and scaling, it’s just that this is no longer the end-users problem. Often people solve this problem by running throw-away databases for playground users via some sort of containerisation service (e.g. kubernetes).
If you can compile a database to WebAssembly, this ‘container’ moves to the user’s browser. They get a very-low latency connection to their own database instance, and you no longer have to host a whole load of short-lived database instances on a server somewhere.
Crunchy Data did just that - compiler Postgres to wasm, allowing fully client-side playgrounds. Awesome.
Running a database client side? that sounds like a really good idea. So good that Postgres isn’t the only one making the move.
The folks behind SpiceDB have compiled their database to wasm, again, for the purposes of supporting online playgrounds. This article covers how they ported their Go app to wasm, and the challenges they faced, for example, non-Go code for specific high-performance functions.
I’m a sucker for retro-games! This tutorial walks through the process of creating a retro shooter game using C# and Uno so that it runs within the browser. You can play the game online here.