Wasm Development Tips&Tricks

Performance

Why is my module binary large?

Some commonly used libraries result in larger than expected Wasm binaries. We have observed an increase in binary size up to 1MB due to inclusion of C++ protobuf library. Minimize the dependencies of a module, and avoid superfluous use of libraries. Prefer single-header libraries such as https://github.com/nlohmann/json or https://github.com/google/flatbuffers.

It is strongly recommended to enable link-time optimization in Wasm compiler.

How can I make my modules consume less memory at runtime?

There is a substantial fixed cost in running each individual module. This cost can be amortized by compiling all modules into one mega-module. This is likely to produce a module that is smaller than the sum of its parts, as well as more efficient than running several modules one by one.

Design

Should I store secrets in the Wasm binary?

We strongly suggest not to place secrets (key information) in the binary. There is no enforcement of confidentiality in the delivery of Wasm binaries, be it via xDS or via file system or via URL fetch. While it is possible to secure the information flow for Wasm distribution, it is not assumed or enabled by default in Istio. In fact, many distribution mechanisms actively cache the binaries (e.g. Docker), making it impossible to prevent accidental persistent storage of key information.

Instead, the secret information should be accessed from an external source. It can be done either via a remote call, or via proposed ABI extensions for secrets.

How do I pass data between modules?

There are two types of data exchange that are supported: sequential and concurrent.

For a single request, modules are executed in sequence and share a common request context. Modules can store and retrieve generic properties by key from this context. The properties can be schematized with either Protobuf or Flatbuffers to enable structural reads (e.g. reading a field in the value instead of the entire value). Please take a look at get_property and set_property ABI calls.

Each worker as well as the singleton main run in individual threads. Modules running in different workers can concurrently access a global table via get_shared_data and set_shared_data ABI calls.

What happens if my module has bugs?

Currently, the host has no protections against liveness bugs in the module. If the module has an infinite loop, the host is not able to take control back, or continue responding to requests.

A panic in the module transitions the VM into a failed state. Typically, this means that no further requests are processed by the host.