Stream: wit-bindgen

Topic: Is WIT suitable for runtime dynamic WASM module loading

Utilize3214 (Nov 09 2024 at 11:00):

I'm trying to figure out the best way to handle dynamic WASM modules in my Rust host. Here's what I'm trying to do:

I've got a bunch of WASM modules (starting with a simple calculator that has add/subtract functions) that I need to load and call at runtime in the host. The tricky part is that for new modules, I won't know the function names at host compile time. The host will read both the module and function names from a file as strings.

All my WASM functions will use the same pattern:

• Take a Vec<serde_json::Value>
• Return a serde_json::Value
• Later on, I want to let these modules use file I/O and make HTTP requests

I've been looking at two approaches:

1. Using wasmtime::Val for dynamic function calls
2. Using .wit files and the component model

The Val approach seems workable for runtime loading, though it requires more boilerplate code and needs a wrapper for type safety. WIT and the component model look great but might not be possible for my use case since they seem to require binding generation and component model setup at compile time.

Key questions:

• Is this a case where using wasmtime::Val directly would be more appropriate?
• Is there any way to handle WIT interfaces dynamically at runtime?
• Or maybe some workaround since I won't know the function names at compile time? Loading different module names at runtime seems fine, but I'm stuck on the function name part.

Any insight is greatly appreciated.

Lann Martin (Nov 09 2024 at 17:40):

There are also dynamic interfaces for component model types, e.g. wasmtime::component::Val

Pat Hickey (Nov 09 2024 at 19:03):

Yeah take a look at component::Val and the rest of the component module, there’s ways to do it all dynamically. E.g. you can get whatever functions exported by a component instance https://docs.rs/wasmtime/latest/wasmtime/component/struct.Instance.html#method.get_func

Pat Hickey (Nov 09 2024 at 19:06):

Wit is most useful to describe component interfaces and worlds ahead of time, if you’re creating those on the fly and handling them at runtime dynamically then wit might not be useful. Wit is “just” a human friendly syntax for the type system that all components have, using wit isn’t required to use components

mainrs (Jul 30 2025 at 12:04):

Sorry to piggyback, but this question fits in well: i have a bunch of microservices in WASM and I want to expose their state in a typed manner to the runtime.

I am using WIT for the service components and want to have a function that exposes their internal state. I can't think of any other route besides defining my own value resource/enum and have functions return that. Similar to serde's Value. Am I unaware of a change that makes this more feasible?

Lann Martin (Jul 30 2025 at 12:43):

If you only need to interact with the state from the host then you can use the wasmtime features described above. If you want two components to share dynamically typed state then you are correct that some kind of resource or enum based approach would be needed (or just use your favorite serialization format).

Lann Martin (Jul 30 2025 at 12:44):

Note that with an enum (variant) approach you cannot model recursive types: https://github.com/WebAssembly/component-model/issues/56

Last updated: Dec 06 2025 at 06:05 UTC