-
Notifications
You must be signed in to change notification settings - Fork 36
Wasm Development Tips&Tricks
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.
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.
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.
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.
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.