WasmCloud is a new and exciting platform for building distributed applications. It orchestrates WebAssembly actors over an asynchronous message queue and is designed for the enterprise with features like signed actors and kubernetes support. WasmCloud alleviates WebAssembly’s missing native functionality by way of a provider concept which links WebAssembly to privileged native code via generic interfaces. Providers deliver a cross platform API to privileged operations, which is what many are waiting for with WASI. As WASI support improves, WasmCloud and its actors becomes more powerful naturally while providers fill the gap for now.
When Vino started, we were also building a platform for distributed WebAssembly. Rather than continue in parallel, we opted to commit and contribute back to WasmCloud and help strengthen the community. WasmCloud has grown to be more exciting by the day and we’re happy to have been around since before it had the name.
WasmCloud builds on top of the WebAssembly Procedure Call project (waPC), a standard protocol for communicating with WebAssembly modules. We had a similar project in the works but also opted to drop it and contribute to waPC instead. These decisions weren’t easy. It’s engineering nature to look at the world and think “here’s how it could be better,” and the nature of modern software means better often starts at the bottom. That’s what we’re trying to change. Vino’s philosophy revolves around reusability and building on top of each other’s success.
WasmCloud actors and Vino components
At the simplest, WasmCloud actors are like language modules for popular platforms like Rust or nodejs. They provide an API similar to a collection of methods. You call them with arguments as input and you wait for their output. With that in mind, picture WasmCloud as a distributed mesh of cross-platform Rust crates or nodejs modules. WasmCloud could also been described as a microservice orchestration platform, but microservices come with baggage that we’d rather leave at the door.
A WasmCloud actor that exposes two methods for changing the case of strings could look similar to below.
Note: This is pseudo code, this is not actual actor code.
This actor’s API should feel intuitive, like using any other code you depend on.
Vino components on the other hand, expose only one method with the same basic signature for every implementation. Each component does only one job and takes its data from a list of input ports and pushes to a list of output ports. To get a better picture, let’s imagine what a
toUppercase component would look like:
Note: still pseudo code.
This looks similar, but standardizing the interfaces for an entire system has far-reaching implications. This is the root of every durable technology, software or otherwise. Each I/O port is an asynchronous, closable stream that can contain both complete messages or sub-stream windows of bracketed data. That’s a mouthful. The gist is that Vino’s ports describe all possible forms of communicating data, removing integration friction and standardizing how code connects. Every input across every component can connect to any like output port on any other component, now or in the future. It’s like USB for code.
Vino calls a complete flow of connected components a schematic which defines how data transforms from request to response. Schematics have the same port interface and can connect as sub-schematics alongside other components. If this still sounds foreign, this mirrors how you likely already build some applications. Message queues, functional reactive programming, event streams, and even piping processes together on the command line all use similar concepts. Vino takes these proven, durable ideas and spreads them everywhere in a way that scales from server to client.
WasmCloud and Vino are two takes on the actor model, with Vino taking its inspiration from flow-based programming, languages like Erlang, and platforms like linux. Vino can run WasmCloud actors and WasmCloud actors can make requests to Vino schematics. You get to reuse and intermix functionality wherever it exists. Building on top of WebAssembly means your applications scales in completely new ways and benefits automatically as WebAssembly support improves.
Components, schematics, and ports are only the first step with Vino. We couldn’t build what we wanted without them.