Skip to main content
Version: 1.x

Capabilities

Overview​

A capability is a reusable, pluggable piece of functionality. Applications implement capabilities for common requirements like storing and retrieving data, accessing secrets, and more. Examples of capabilities include:

  • Key-Value Storage for caching (think Redis)
  • Messaging for persistent message (think Kafka)
  • Blob Storage for long term data storage (think S3)
  • Secrets for secret management (think Vault)
  • HTTP Client for sending HTTP requests
  • HTTP Server for receiving HTTP requests
  • Logging

You can find a complete list of first-party capabilities in the Capability Catalog.

How capabilities work​

Capabilities are enacted by an interface and one or more swappable capability providers. A provider delivers a specific implementation of a given capability by communicating with other entities in the common tongue of a standard API in WebAssembly Interface Type (WIT).

For example...

  • The Redis key-value storage provider delivers the key-value capability to application components over the standard wasi:keyvalue API.
  • The team can use the same wasi:keyvalue functions—for example, get, set, delete, and exists—regardless of your intended capability provider.
  • If the development team chooses to use Vault for key-value storage instead, they can swap out the Redis provider for the Vault provider.
  • The Vault capability provider will deliver a different implementation of the same capability over the same API.

Creating your own capabilities​

wasmCloud supports custom capabilities—use our provider SDKs for Rust and Go to create your own providers, and write your own interfaces in the WebAssembly Interface Type (WIT) interface description language.

Note

The long term plan is to be able to develop capability providers as Wasm components. Providers are fairly simple, only needing to handle NATS subscriptions for wRPC, generate types from WIT, and then execute as a standalone binary. Enabling Wasm component providers would remove the complexity of cross-compilation and the need to execute as a native binary, as well as improving performance and security. We're continuously evaluating the Wasm landscape to determine when we can make this shift.

For more information, see...