Topic: Discuss ins & outs, pros & cons, opportunities & threats of WebAssembly for edge computing.
The WebAssembly-related standards are being extended beyond the browser realm, for use “on the edge”, meaning that modules and components can run anywhere i.e. cloud, server, browser, IoT and mobile devices. Many languages are adding compile targets for Wasm. The Component Model and WASI built on top allow for interface-based polyglot programming…
An individual compiled WebAssembly module is an efficient binary .wasm file that can execute with near-native speed (though currently not for all languages and environments… much is still early days). Eventually wasm is to be fully hidden from the application developer as a technology further down the stack.
My thinking was that this emerging technology is a good fit for @akkartik’s Freewheeling apps with its sandboxing and freedom to choose any language + stack.
This week is the first WebAssembly conference:
Below I collected some (admittedly buzzword-laden) resources for those who want to know more…
The introduction of WASM for edge computing is more far-reaching than initially apparent. It opens a completely new paradigm to Component-based architecture.
I have to admit, I’m a bit wary of WebAssembly. It might have to do with the ‘Web’ in the name, but I tend to focus on the people creating and pushing a technology, and for the most part (with exceptions such as WebGPU and yourself) WebAssembly feels a bit too trendy and hype-y for my taste. I’ve seen enough cases in the past where big companies get into a promising technology, and it never ends well for my priorities.
The component model could be quite powerful for malleability in my view!
The component model is a proposal actively in development for what looks like a package system from other ecosystems, but with some unique features including:
clearly defined types at component boundaries
parent components can define how child components are wired together (instead of only the child importing within itself)
In my view, this seems like a great layer upon which to build malleable extensibility. The link-time virtualisation example hints at the “rewiring” power I am thinking of for malleable purposes.
I’m hoping to get better at writing about my own malleable thoughts on this extensibility topic and others on my blog in the next weeks / months… I just need to force myself to block off the time to do it properly.
Beyond the component model, I also see malleable connections in allowing language choice / polyglot extensibility. You would be able to use whichever language you prefer, as long as it compiles to Wasm. Of course, there are still some open problems around polyglot language semantics to ensure the combined multi-language program actually does something sensible… even with that in mind, I see this as quite an enticing way to side-step programming language preferences by supporting many of them in one go.
Being wary is certainly prudent. As with all major technology efforts the infamous hype cycles there’s danger to going all-in too soon. There’s a lot of nice experimentation as well as actual product development going on, both by established parties (corporations) and tinkerers on the Fediverse and HN.
From my own surveys of the emerging technology landscape I became confident enough to say that I’d like to consider being an early adopter, and knowing full well that that entails frequent changes and shifts as well as open areas for research. But that last bit is a Good Thing™. Unleash the creativity
Indeed. In the last wasmCloud community meeting there was a demonstration of a very basic KVCounter in Golang (port of a similar example in Rust) and based on a simple WIT world definition + codegen, the code itself is completely void of infra-specific stuff. And even more there’s zero lines of code that it makes it a wasmCloud application. It just runs on that platform based on all the open standards it supports. The only specific line that makes this happen is in the compilation directive:
This is just a prototype, and the codegen can be much cleaned up (e.g. now generates very long names).
This extends (pun intended) seamlessly to the above. Components can be composed from modules written in any Wasm-supporting language. And create powerful plugin architectures. Extism is a prime example of a project focused on that, among others.
Where I’m interested is in having very loosely-couple event-driven architecture and orchestrated “service modules” be the building blocks for creating “social experiences”. Reviving the idea of Social experience design (SX) that builds upon DDD Strategic design to allow non-technical stakeholders to be always in lock-step with the software team and see their Needs covered. All this relates to the Solidground Project, where we’ll go with a new Rust + Wasm stack.
PS. I’ll drop some notes about wasm survey I did. But that requires some editing to upload imgs. Will do later.
That’s one of the features I find interesting, because we desperately need better ways to build bridges between software components from different universes. But this crucially depends on the availability of diverse languages on the wasm platform, plus practically usable interfaces. For now, I see mostly languages aiming at low-level and/or highly formalized problems. I vaguely remember comments about garbage collection being difficult to do on wasm - that could become a show stopper if it’s a fundamental issue.
That’s the problem with pretty much any interop technology I have seen so far (I stopped counting them). They never reach a sufficient coverage of language space even for evaluating the ideas in practice.
One huge adopter being Cloudflare in their Cloudflare Workers, with Kenton Varda of Cap’n Proto also the architect of Cloudflare Workers. Not entirely sure how that is done…
See excerpt from Workers docs mentioning Cap'n Proto
Currently, Workers does not allow any access to the local filesystem. Therefore, Cloudflare does not expose a filesystem API at all. No API means no access.
But, imagine if Workers did want to support local filesystem access in the future. How can that be done? Workers should not see the whole filesystem. Imagine, though, if each Worker had its own private directory on the filesystem where it can store whatever it wants.
To do this, Workers would use a design based on capability-based security. Capabilities are a big topic, but in this case, what it would mean is that Cloudflare would give the Worker an object of type Directory, representing a directory on the filesystem. This object would have an API that allows creating and opening files and subdirectories, but does not permit traversing up the parent directory. Effectively, each Worker would see its private Directory as if it were the root of their own filesystem.
How would such an API be implemented? As described above, the sandbox process cannot access the real filesystem. Instead, file access would be mediated by the supervisor process. The sandbox talks to the supervisor using Cap’n Proto RPC, a capability-based RPC protocol. (Cap’n Proto is an open source project currently maintained by the Cloudflare Workers team.) This protocol makes it very easy to implement capability-based APIs, so that Cloudflare can strictly limit the sandbox to accessing only the files that belong to the Workers it is running.
The excerpt gives an example of allowing filesystem access using Cap’n Proto. The sandboxing of Wasm combined with WASI capability-based security gives OOTB support for similar use case as well, and Cloudflare Workers already has (some, because not up-to-date) experimental WASI support.
WASI Preview 2 is based on WIT IDL (that allows you to specify the contracts/interfaces that facilitate communication with a Wasm component in controlled manner (i.e. per resource capabilities)). The idea is that WASI provides a range of fully standardized interfaces. Currently there are a number of Proposals going through a standards process (note too that the Wasm docs are messy and doing catch-up to inform on current reality, with an ecosystem that is moving quite fast).
Topic: Discuss ins & outs, pros & cons, opportunities & threats of WebAssembly for edge computing.
