Skip to main content
← Back

Hono on Wasm, Component Saturation Metrics & the NATS Statement

The April 30, 2025 wasmCloud community call centers on the Wasm component model and the JavaScript ecosystem reaching it. Milan Raj demos the Hono web framework compiled to WebAssembly with JCO and TypeScript — JSX server-side rendering, OIDC authentication, and a fully typed OpenAPI service — showing how much of the JS ecosystem just works inside a component. Brooks Townsend then demos new component-instance saturation metrics over OpenTelemetry, walks a large refactor that makes the wasmCloud host embeddable behind pluggable traits, and leads a candid community discussion on the proposed CNCF NATS.io licensing and ownership changes.

Key Takeaways​

  • Hono runs as a WebAssembly component via JCO and TypeScript — because Hono is built on web standards, the app.fire helper collapses the adapter boilerplate to a single line, and the same component code also runs in Node for step-through debugging
  • Milan layered on JSX server-side rendering, OIDC middleware (Google and GitHub OAuth, with cookie-based session handling), and a transparent HTTP proxy — all "just working" inside the component
  • A Hono + Zod OpenAPI demo gave strong typing across the whole API surface, auto-generated Swagger docs, and Apache Bench benchmarking; cold start was a millisecond or two, and bundles came in around 11–14 MB with all assets compiled in
  • Brooks demoed two new observability metrics — component active instances and max instances — that you can express as a saturation ratio in Prometheus and wire to alerting (PR #4398)
  • A large refactor (PR #4407) makes the wasmCloud host embeddable by hiding event publishing, configuration, data stores, secrets, policy, and the control interface behind simple traits — with NATS implementations remaining the default and no breaking changes to the binary
  • wRPC's transport abstraction already supports TCP and Unix domain sockets alongside NATS; the remaining tightly coupled pieces are the native provider API and target routing
  • wasmCloud published a statement on the proposed CNCF NATS.io changes reaffirming its commitment to open source and the CNCF — and, the day after this call, CNCF and Synadia issued a joint statement that NATS trademarks stay with the CNCF and licensing will not change

Chapters​

Meeting Notes​

Impromptu Demo: Leveraging the JavaScript Ecosystem in Wasm Components​

Milan Raj from National Instruments (Emerson test and measurement) opened with a surprise demo of his wasm-component-examples repository. National Instruments builds a graphical programming language that compiles to web applications, so Milan's team has been deep in front-end WebAssembly for years; with WASI Preview 2 they have been pushing it on the back end too. His question: how much leverage can you get from existing JavaScript libraries and frameworks inside a WebAssembly component?

His answer is the Hono web framework, compiled to a component with JCO and TypeScript. Because Hono is built on web standards — passing standard fetch-based request/response objects and supporting the service-worker fetch event used by ComponentizeJS — Milan could replace all of the adapter code from the existing wasmCloud Hono example with a single app.fire call. He structured every example to run both as a component (under Wasmtime or wasmCloud) and in Node, so he can set breakpoints and step through the same code while developing.

From there it was a tour of "it just works":

  • JSX server-side rendering with strongly typed props, following Hono's stock React-JSX tutorial unchanged.
  • OIDC middleware wired to Google OAuth — Milan upstreamed patches to the JCO OIDC middleware — with cookie-based session management, so no separate key-value store is needed. A second, unchanged plugin handled GitHub OAuth.
  • A transparent HTTP proxy to httpbin.org working out of the box.

Lachlan Heywood noted he had independently added the wasmCloud Hono example and converged on the same single-line adapter pattern, with StarlingMonkey as the engine running JavaScript inside Wasm — a nice case of simultaneous discovery, and a sign of how fast this tooling is maturing.

Hono OpenAPI, Zod Typing, and Benchmarking​

Milan's deepest example used Hono's OpenAPI middleware with Zod to type the entire API surface. Defining routes via app.openapi and Zod schemas yields strong typing of inputs and outputs (the compiler complains if a response is missing a required field), auto-generated OpenAPI/Swagger documentation rendered at the root, and live "try it out" testing. He also instrumented Apache Bench benchmarking.

On performance: cold start was a millisecond or two; a warmed-up Node process eventually JIT-optimizes to be faster on a heavy Zod-validation workload, but with validation removed the component was nearly identical to Node. Bundle sizes — with all assets compiled in — ran roughly 11 MB for the bare-bones example up to 14 MB for the full Hono features app. AOT compilation blew the size up considerably, so Milan set it aside for now.

Demo: Component Instance Saturation Metrics​

Brooks Townsend demoed two new metrics he had just added (collaborating with Milan): component_active_instances and component_max_instances. Running the OpenTelemetry Docker Compose example with WASMCLOUD_OBSERVABILITY_ENABLED=true and the HTTP-to-Redis key-value counter component, he queried Prometheus to watch active instances climb under load (a concurrency-100 Apache Bench run pushed it to ~22 active instances against a max scale of 100). Expressing active over max as a saturation ratio turns raw counts into a percentage you can alert on — for example, paging at 80–90% saturation. The work landed in PR #4398 and is part of a broader push to use OpenTelemetry observability to answer production questions like "how many instances are running, and do I need more headroom?"

Discussion: Making the wasmCloud Host Embeddable​

Brooks then walked a large but mostly-refactor PR (#4407) aimed at making the wasmCloud host genuinely embeddable. The wasmcloud binary already just embeds the host crate, but the host's behavior was tightly wired to NATS. The PR moves event publishing, configuration, data stores, secrets, policy, and the control interface behind small, simple traits (the data store is just get/put/delete/watch, for instance). You can now feed events to a channel — or turn them off entirely — and supply a hash map instead of a NATS JetStream bucket. The default NATS implementations stay in-tree, the binary behaves exactly as before, and there are no breaking changes — but embedders get a lot more knobs.

In the Q&A, the contributor "ossfellow" pushed on the runtime's hard-coded wRPC usage and the desire for provider chaining and alternative transport implementations. Brooks agreed: the goal is for the host to consult a simple routing abstraction ("this component wants to call this interface — where do I send it?") that could resolve to an in-memory component, a wRPC NATS transport, or an error. Vance Shipley asked whether wasmCloud is "becoming more polyfill over time," and Brooks framed the direction positively — a pluggable, extensible platform that leans into host plugins and standards.

Discussion: The Proposed CNCF NATS.io Changes​

The final agenda item was the wasmCloud team's statement on the proposed changes to CNCF NATS.io licensing and ownership. NATS has been a core part of wasmCloud since the earliest ADRs, so the maintainers wanted to reassure the community: wasmCloud is committed to the CNCF and to open source, and NATS remains central to its distributed story regardless of the outcome. Milan asked how decoupled wasmCloud could already be; Brooks shared an architecture diagram showing that after the traits PR, the only tightly coupled pieces left are the native provider API and target routing — everything else (config, control interface, data store, secrets, policy, events) now has a lightweight abstraction with NATS as the default. Florian Fürstenberg asked for those diagrams to land in the docs, which Brooks agreed to pursue.

Jochen Rau offered that the abstraction work makes wasmCloud a better product by forcing clean separation of concerns, and confirmed his team (machine metrics / IIoT) will stick with NATS regardless. Vance Shipley framed the moment as an opportunity to build "low-impedance bridges" between the Erlang/distributed world and WebAssembly. The conversation continued candidly past the formal wrap-up — community members shared real frustration with how the change was communicated and brainstormed commercial models that could fund the work without changing the license.

Update: On May 1, 2025 — the day after this call — CNCF and Synadia issued a joint announcement that NATS trademarks will remain with the CNCF and the project's licensing will not change.

WebAssembly News and Updates​

This call captures the JavaScript ecosystem arriving at the Wasm component model in force. Hono — a web-standards-first framework born from Cloudflare Workers — compiles cleanly to a component through JCO and ComponentizeJS, with StarlingMonkey running the JavaScript inside Wasm. JSX rendering, OIDC auth, OpenAPI/Zod typing, and HTTP proxying all worked with little or no adapter code, and the "run the same source in Node or as a component" workflow makes debugging painless. The maturation here is striking: six months earlier this was nowhere near as easy. For broader ecosystem updates, follow the Bytecode Alliance and the WASI subgroup.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and more) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, uses NATS for transport and distributed communication by default, and — as this call shows — is increasingly embeddable and customizable behind pluggable abstractions. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Nearly every thread in this meeting traces back to the Wasm component model. Milan's Hono demos work precisely because the component model lets TypeScript/JavaScript code — compiled through JCO with StarlingMonkey — present a standard, typed interface to the host: a single component can serve HTTP, render JSX, and broker OIDC without the host knowing or caring what language wrote it. Brooks's component-instance metrics measure exactly the unit the component model defines — instantiated components running at a point in time — which is what makes "active vs max instances" a meaningful saturation signal. And the host-embeddability refactor is, at heart, about cleanly separating the runtime that instantiates components from the NATS-flavored plumbing around it, so that the same component model can run inside someone else's custom host over whatever transport they choose. As more of the JavaScript ecosystem (Hono, Zod, OIDC middleware) and more runtimes reach the component model, "write a component once, run it in any language's host" keeps getting closer to reality — and wasmCloud's bet is that the component model is the universal contract beneath it all.

Who Should Watch This​

This call is especially valuable for JavaScript and TypeScript developers curious how far the JS ecosystem already runs inside Wasm components (start with Milan's Hono demos from 6:48), platform and SRE teams instrumenting WebAssembly workloads who want production saturation signals over OpenTelemetry (Brooks's metrics demo at 38:59), and Rust developers and platform builders interested in embedding the wasmCloud host behind their own abstractions and transports (the embeddability discussion at 46:34).

Up Next​

The threads here continue in upcoming calls: more OpenTelemetry observability signals for answering production questions, the ongoing work to make the host pluggable and embeddable (TCP and Unix-domain-socket transports, provider chaining, and target routing), and tighter integration between the JavaScript/TypeScript toolchain and wasmCloud templates. With the CNCF/Synadia joint statement settling the NATS question, NATS remains the default transport while the pluggable abstractions give teams options.

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 →