A WebAssembly (Wasm) module is a compiled program that runs inside a virtual runtime. A host can call it through a defined interface without needing to know how its implementation works. That makes the module useful as replaceable application logic: another module can take its place if it fulfills the same interface, even while the host keeps running. section 10.1 section 10.2
The boundary also matters for safety. A module runs in a sandbox and receives input through direct arguments or its own memory buffer. For data that does not fit simple arguments, the host must work with the module's memory-management and reading functions. The calling service must explicitly permit access beyond that boundary. section 10.1
Compile and run an API search
Keep API-search logic in a Rust library, then make a separate binary call it and print the results. Compile the binary for the wasm32-wasi target to produce a .wasm file, and run that file with WasmEdge. A command-line search term can change the query without changing the compiled module. Separating the library from the binary keeps business logic out of the application entry point. section 10.2
Listing 10.14 Command: Building Wasm
cargo build --target wasm32-wasi #1 wasmedge target/wasm32-wasi/debug/paper_search.wasm #2
The build command produces the Wasm file; the next command runs it in WasmEdge. section 10.2
The same file can instead be consumed by a Rust executable. Using the WasmEdge SDK, the host configures WASI, registers a module from its file, and runs a function such as _start or static_search. This changes the integration point without requiring the module's logic to be rewritten into the host. The trade-off is an interface and module dependency that still need deliberate design. section 10.4
