Skip to main content
← Back

TypeScript Templates, Component Interposition Middleware & A C-Advisor for WebAssembly

Watch on YouTube ↗

The February 4, 2026 wasmCloud community call covers the home stretch of v2 hardening and two strong outside demos. Eric walks through the new TypeScript template conventions for v2 — interface-named templates, standardized config.yaml for auto dev/build, package and world naming, gitignored generated artifacts — landing in the wasmCloud TypeScript repo. Elizabeth Gilbert demos component-interposition, her WASI P3 project that interposes middleware components between an HTTP request and a service — single middleware, then three nested onion-style — with the full WAT walkthrough showing exactly how the wac DSL composes the chain. Marcin Ziółkowski presents his work on a C-advisor equivalent for WebAssembly, hitting the wall of how to measure per-instance resource consumption when Wasm runtimes don't sit cleanly inside cgroups; Lucas walks him through the thread-pinning angle, and the call connects him with Elizabeth and the Wizard research engine community. Bailey also covers v2 RC7, the upcoming repo reconciliation that merges wash into wasmcloud/wasmcloud, the imminent WASI 0.2.10 release, and the next WASI P3 RC.

Key Takeaways​

  • wasmCloud v2 RC7 is out with docs revved; the team is feature-complete and in the hardening / developer-ergonomics phase
  • TypeScript template conventions for v2 landed — interface-named templates (http-hello-world, http-service-hono, http-client), config.yaml for automatic dev and build, standardized package/world names (wasmcloud:templates, world typescript), required README, gitignored deps and generated bindings
  • Templates vs examples distinction is now explicit — templates are robust scaffolds for developers to start from; examples are fleshed-out demonstrations of combined functionality
  • Cross-language template name parity — when there's an HTTP client template in TypeScript, there'll be one with the same name in Rust, Go, etc., so developers can guess the path without grepping
  • Repo reconciliation coming next week — wasmcloud/wasmcloud v1 main moves to a new wasmcloud-v1 repo; wash repo content takes over main of wasmcloud/wasmcloud; release-candidate cuts and v1 work pause briefly during the migration
  • Jeremy's WASI OTel host plugin is in draft PR, with a live demo coming next week — wraps wash-runtime host with OTel and uses the same connection for component-level observability
  • Component interposition demo — Elizabeth Gilbert showed nested middleware on a WASI P3 service: HTTP request → middleware A → middleware B → middleware C → service → unwind back out. The composition is all WIT + wac, no network hop, and could replace heavyweight envoy sidecars for observability, security, and service chaining
  • A C-advisor for WebAssembly is a real gap — Marcin Ziółkowski showed the current state (PID-based reads of cgroup data) and surfaced that Wasm runtimes don't naturally pin instances to OS threads, which is what makes proper per-instance cgroup accounting hard; Lucas connected the dots on the path forward
  • WASI 0.2.10 released yesterday — possibly the last 0.2.x release; the next P3 RC cuts this week and may be the one that goes to vote
  • gRPC support likely targeted for v2.0 if a timebox this week resolves the Wasmtime fixture issue; otherwise a point release
  • wasmCloud v2's homogeneous multi-tenancy is dense — Lucas highlighted that when 10 deployments use the same OCI artifact, v2 loads the component into memory once and instantiates per request, vs. v1 which loaded it 10 times

Chapters​

Meeting Notes​

Eric's TypeScript Template Conventions for v2​

Eric opened with the philosophy and conventions for v2 templates landing in the wasmCloud TypeScript repo. Templates are meant to be robust (enough functionality to build a real app) and approachable (idiomatic, standard APIs — std for Rust, the standard web APIs like fetch for TypeScript, generated bindings kept under the surface).

Conventions adopted across templates:

  • Interface-based explicit names: http-hello-world, http-service-hono, http-client. The name tells you exactly what interfaces it demonstrates.
  • config.yaml for wash that enables automatic dev and build on download (so wash new → it works)
  • .gitignore standardized per language toolchain, excluding generated bindings and WIT dependencies; templates fetch deps and regenerate bindings on dev or build
  • Standardized package and world names in world.wit: package wasmcloud:templates, world named for the language (e.g., typescript)
  • A README is required

Eric demoed http-hello-world (9 lines of code, 7 of them meaningful, returning "Hello from TypeScript" via the Fetch API) and http-client, which has multiple endpoints for making outgoing HTTP requests, proxying, headers, JSON, and supports multiple methods — all using fetch. Both run cleanly with wash dev.

Templates vs examples: templates are robust scaffolds developers start from; examples are flashier demonstrations of combined functionality designed to show off what wasmCloud can do. Bailey added a key point: cross-language template name parity is the goal. When there's an HTTP client template in TypeScript, there will be one with the same name in Rust, Go, etc., so developers don't have to grep around.

v2 RC7, Repo Reconciliation, and WASI 0.2.10​

Bailey covered the v2 status:

  • RC7 is out with docs revved. The team is feature-complete and in hardening + ergonomics mode.
  • Victor is cutting the last v1 wash release as the call is happening.
  • Once that lands, the repo reconciliation begins, probably next week:
    • Current wasmcloud/wasmcloud content (the v1 codebase) moves to a new wasmcloud-v1 repo
    • Current wash repo content takes over main of wasmcloud/wasmcloud
    • CI is redone, things get republished
    • Release-candidate cuts and v1 work briefly pause; Bailey will announce the start in Slack

The runtime that lives inside wash — currently called "wash runtime" in some references — will likely be renamed. ossfellow flagged that wash is synonymous with the CLI for long-time users, so "wash runtime" sounds odd. Bailey agreed and floated wasmgov-runtime or wasmcloud-runtime as candidates.

Jeremy's WASI OTel Preview​

Jeremy Fleitz has been working on a wasi-otel host plugin for the past week — draft PR up, demo planned for next week's call. It lets components emit OpenTelemetry through the host, sharing the same connection as host-level OTel. By default it's off (OTel can be noisy); when you want to enrich the OTel context from inside your component, you import wasi-otel.

gRPC Status​

Aditya asked in chat whether gRPC support lands in v2.0 or a point release. Bailey and Lucas's read: the structure of the PR is good but has drifted from what was there before, and there's a complication with the test fixtures around Wasmtime. Timebox: if it can be resolved this week, target v2.0; if not, defer to a point release. Bailey suggested some pairing time to scope the work.

WASI 0.2.10 and the Next P3 RC​

Bailey released WASI 0.2.10 yesterday — possibly the last 0.2.x release. The 0.2.10 changes are mostly doc updates, additive, and feature-gated.

The next WASI P3 release candidate will cut later this week. The previous RC (cut January 6) shipped the completed component model ABI — no more changes expected at the ABI level. Iteration since has been on wasi-cli ergonomics for async and features, with the file system space being the active workshop. The next RC may be the one that goes to vote — possibly as early as March.

Elizabeth Gilbert: Component Interposition Middleware​

Elizabeth Gilbert demoed component-interposition, a working WASI P3 project showing middleware composition between HTTP and a service via the component model. The repo digs into the low-level WAT (WebAssembly text format) so contributors can see exactly what's happening at the ABI level.

Pattern:

  • An incoming HTTP request hits the outermost middleware
  • That middleware logs and passes the request to the next handler in the chain — without knowing what comes next
  • Three middlewares (A → B → C) onion-style around a service at the core
  • The response unwinds back through C → B → A and out

The middleware WIT imports a handler and exports a handler — that's the "secret sauce." wac (the WebAssembly Composition DSL) wires the chain: instantiate the service, plug its export into the innermost middleware's import, plug that into the next, and so on, finally exporting the outermost handler. Elizabeth's next iteration: splice middleware between two composed services (e.g., service A calls into service B's exported component functions, and middleware lives between them) — a more advanced composition pattern.

Frank Schaffa compared this to Aspect-Oriented Programming — the HTTP call is the "point cut." Elizabeth confirmed the analogy. Bailey reframed: wasmCloud calls this service chaining, and middleware is a specific specialization with a middleware world that imports and exports a handler. Because it's all WIT interfaces composed at build time, there's no network stack hop — calls cross interface boundaries inside a single Wasmtime store.

Frank's use case: inject debugging or tracing on every request, route to OTel. Elizabeth: observability, security protocols, basically anything you'd put in a sidecar. Bailey: this likely replaces what people do with envoy sidecars — including service breakers and other heavyweight network-side concerns. Wac is machine-readable and writable, so the composition can also be generated.

Marcin Ziółkowski: C-Advisor for WebAssembly​

Marcin Ziółkowski (Orange Innovation Poland, PhD candidate) presented his ongoing work on a C-advisor equivalent for WebAssembly. The motivation: testing the typical claims about Wasm — faster, smaller memory footprint, better density — for services Orange has compiled internally. He went looking for a cadvisor-style tool to measure per-instance resource consumption and didn't find one.

His current approach reads from the /sys/fs/cgroup directories and uses the PID of a running runtime instance (Wasmtime, WasmEdge, anything) to capture CPU and memory metrics — but that captures both the runtime and the Wasm instance combined. What he wants is per-instance resource accounting, and that's where existing tools fall short.

Bailey's first pass: OpenTelemetry semantic conventions for Wasm resource metrics is the natural path here. v1's OTel demoed last meeting is the foundation; v2 will extend it but doesn't yet have the per-instance memory and CPU breakdown Marcin wants. Bailey also flagged the observer effect — gas instrumentation slows things down significantly, and gas is implemented differently across runtimes, so it isn't a portable measurement.

Lucas Fontes laid out the architectural answer: to get a Wasm component to behave like a cgroup for measurement, you need to pin a component to a specific OS thread. Most Wasm runtimes are heavily async/multi-threaded, which means a single component's work can move across threads, defeating any cgroup pinning. There's a known PR addressing this in the runtime (he linked it in chat). Once a thread is pinned, putting it in a cgroup is trivial — and at that point Marcin's existing C-advisor approach works.

Lucas's secondary point: Wasm components already start with limits baked into the ABI — when a runtime gives a component memory, it tells the component "here's your area, you can grow to X." With wasmCloud v2, those limits and the request-level accounting are present but not yet surfaced through OpenTelemetry. The pieces are in place; the missing layer is metric surfacing.

Lucas also flagged the homogeneous multi-tenancy density in wasmCloud v2 as relevant: when 10 deployments reference the same OCI artifact, v2 keeps the component in memory once and instantiates per request, where v1 loaded it 10 times. That changes the per-component overhead numbers dramatically and is worth testing against.

Frank Schaffa raised eBPF and flame-graph tooling as another angle. Bailey: eBPF runs into the same process-pinning problem unless the thread-pinning work lands. Liam Randall mentioned swoll, the Capital One-built eBPF tool for fleet-wide syscall tracing — useful at the abstraction layer below Wasm but doesn't pass through to the per-component level. Bailey pointed at Sightglass, the Bytecode Alliance benchmarking suite, which has flame graphs and is the canonical place for cross-release Wasmtime/Cranelift performance comparisons.

The team cross-connected Marcin and Elizabeth (both PhD students working in this space) for follow-up; Liam offered to make the email intro.

WebAssembly News and Updates​

This call sits at the convergence of WASI P3 stabilization and the maturation of the component model composition story. Elizabeth's component-interposition demo is the kind of pattern that makes the "WebAssembly replaces sidecars" pitch concrete and demonstrable. JCO and wac continue to give the component-model real production tooling. Meanwhile, the missing observability story — per-component resource accounting — is a real gap that Sightglass covers for benchmarking but no production C-advisor analog yet handles. Once thread pinning lands across major runtimes, the cgroup path opens up.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly components across cloud, edge, and Kubernetes. The v2 architecture introduced in this call's RC7 release moves wasmCloud to a Kubernetes-native operator pattern with homogeneous multi-tenancy density — multiple deployments referencing the same component share one in-memory load, with per-request instantiation. Components compose with the runtime via WIT interfaces (HTTP, KV, Blobstore, OTel, sockets) using the component model, can be chained with middleware components in process via wac composition (no network hop), and ship with built-in OpenTelemetry observability, declarative workload deploys, and signed/attested OCI artifact distribution.

Topic Deep Dive: Component Interposition as a Sidecar Replacement​

The component-interposition demo is the architectural argument for why the WebAssembly component model matters operationally, not just at the language-portability level. Today, a Kubernetes platform team deploying envoy as a sidecar for observability, mTLS, rate limiting, or circuit breaking pays a real cost: a second container per pod, a network hop between application and sidecar, and a separate config/lifecycle to manage.

With component interposition, those concerns become WebAssembly components composed into the same workload. The application's HTTP handler is wrapped by a middleware whose wasi-http handler import is bound to the inner component's handler export — there's no network stack between them, just an interface call inside a single Wasmtime store. You can compose multiple middlewares onion-style for observability, security, and rate-limiting concerns, each as a small auditable Wasm component. The composition is declarative in wac, which means it's machine-readable, version-controllable, and generatable from a platform's higher-level config.

For platform engineers, the immediate evaluation point is whether the wasmCloud Kubernetes operator plus component interposition can credibly replace the sidecar-per-pod pattern. The demo shows the primitive works; the v2 release brings the operator and host plugin model that makes it deployable at scale.

Who Should Watch This​

TypeScript developers building wasmCloud applications should start with Eric's template walkthrough at 05:24. Platform engineers thinking about sidecars and service mesh want Elizabeth's component-interposition demo at 22:08 and the wac DSL walkthrough at 32:10. Anyone working on WebAssembly observability and measurement should watch Marcin's C-advisor presentation at 36:11 and Lucas's thread-pinning answer at 44:13.

Up Next​

Next week (February 11): Jeremy's full WASI OTel host plugin demo, more templates (TypeScript and Rust), and continued v2 hardening. The repo reconciliation work begins probably next week — Bailey will announce in Slack. The next WASI P3 release candidate cuts this week, likely the last before the vote in March.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →