[Exploration] WIT + Component Model: toward a formal host API for numax

[GianIac]

After an insightful conversation with @tschneidereit (Till Schneidereit) on Bytecode Alliance Zulip, I realized that adopting WIT and the WASM Component Model could have significant benefits for the future of numax, replacing or complementing our current hand-written host ABI.

Currently, numax exposes its host APIs (db, crdt, log, ...) as raw WASM imports, defined manually in HOST_API.md and implemented by hand both in the runtime (nx-core) and the guest SDK (nx-sdk). This works, but every new function means touching the host linker, the SDK wrappers, and the docs separately with no single source of truth.

Why consider WIT / Component Model?

• The host API becomes an actual contract, not just documentation.
• Guest SDKs in C, C++, Go, Zig, Python... could be generated automatically from the same .wit file, exactly what the current example issues (Add first non-Rust guest example in C #49, Add a minimal C++ guest example for Numax #52) are solving manually today.
• WASI Preview 2 is built on top of the Component Model, aligning now avoids a larger, more painful migration later.
• Wasmtime already has first-class Component Model support, so the runtime side is not starting from scratch.

Open questions:

This is not a task yet, it's a mode to think out loud and collect input before any implementation decision.

Should numax define its custom APIs (numax:db, numax:crdt) in WIT as a formal contract, independently of WASI?
Should we start with WIT as living spec only, keeping the current raw ABI underneath, or go straight to a full Component Model guest?
What would the migration cost look like for existing nx_sdk guests?
Is it realistic to support both ABIs in parallel during a transition period?
Any prior art, experiments, or opinions from the community?

All feedback welcome. even half-formed thoughts.

[claudius108]

I would gradually align everything with the existing standards.