Skip to main content
Version: 1.0

Interfaces

Overview​

In wasmCloud, components and providers communicate through interfaces, sometimes called capabilities.

WebAssembly Interface Type (WIT)​

wasmCloud supports interfaces belonging to WebAssembly System Interface (WASI) 0.2 and custom interfaces written by third parties. In all cases, wasmCloud interfaces are defined using WebAssembly Interface Type (WIT) interface description language (IDL), an open standard maintained as part of the Component Model by the W3C WebAssembly Community Group.

WIT is designed to allow WebAssembly components to define the interfaces they support ("exports") and the capabilities they need ("imports"). wasmCloud also uses WIT to define the interface/contract provided by capability providers.

WASI interfaces​

WASI 0.2 includes these APIs, all available for use with wasmCloud 1.0:

APIVersions
https://github.com/WebAssembly/wasi-io0.2.0
https://github.com/WebAssembly/wasi-clocks0.2.0
https://github.com/WebAssembly/wasi-random0.2.0
https://github.com/WebAssembly/wasi-filesystem*0.2.0
https://github.com/WebAssembly/wasi-sockets*0.2.0
https://github.com/WebAssembly/wasi-cli0.2.0
https://github.com/WebAssembly/wasi-http0.2.0
Sensitive interfaces

As a security-first platform, wasmCloud provides stubbed implementations of wasi-filesystem and wasi-sockets that don’t truly interact with the host system. For functionality that depends on these interfaces, we recommend using wasi-virt to virtualize your component.

Additionally, wasmCloud supports proposed WASI APIs that are in the process of implementation and standardization:

APIVersions
https://github.com/WebAssembly/wasi-blobstore0.2.0-draft
https://github.com/WebAssembly/wasi-keyvalue0.2.0-draft
https://github.com/WebAssembly/wasi-logging[proposal]

Custom interfaces​

WASI interfaces are ultimately common standards using WIT, but wasmCloud enables you to build custom WIT interfaces and communicate between components in the way best-suited to your requirements.

Here is an example of a greeter interface defined in WIT:

wit
package local:greeter-demo; // <namespace>:<package>

interface greet { // interface <name of interface>
  greet: func(name: string) -> string; // a function named "greet"
}

world greeter {
  export greet; // make the `greet` function available to other components/the runtime
}

While reading the spec is the best way to learn about WIT, it is also designed to be easy to understand at a glance. WASI interfaces written in WIT contain their own documentation and are useful to consult as examples.

Comparing to gRPC and Smithy

While similar frameworks and languages like gRPC and Smithy are meant to perform over network boundaries, WIT is in-process, and performs at near-native speed.

Interface-driven development​

Interface-driven development (IDD) is a development approach that focuses on defining what capabilities components require before the specifics of how you will meet those needs. Systems developed using IDD—especially distributed systems—are loosely coupled, robust, and maintainable.

By default, WebAssembly components operate in a completely isolated sandbox, meaning that they can only perform logical operations with no access to system resources like I/O, networking, and syscalls. In functional programming terminology we might call these components "pure," as they can only map inputs to outputs without producing side-effects. But without any side-effects, how can we use WebAssembly components to do anything useful in our applications?

Keep reading​

Continue to learn more about how the wasmCloud host, or...