WASM RPC standard proposal?

[JMLX42]

Hello,

First of all this is the first time that I write this kind of issue/proposal. So please excuse my bluntness or anything that might be missing/lacking. I'll gladly complete this post through comments and edits.

Considering:

• The WASM standard introduces a portable way (using WAT text or actual WASM binary) to represent function calls.
• The WASM Interface Types introduce a portable way to expose scalar (and compound?) types.
• HTTP2 and onward offer bidirectional communication between clients/servers

one might think we have a portable/standard way to define a Remote Procedure Call (RPC) system.

By comparison to a well-known industry leader such as gRPC:

• gRPC messages can be "replaced" by Interface Types.
• gRPC services can be "replaced" by WASM (binary) or WAT (text) function call instructions.
• gRPC HTTP2 transport layer would fit perfectly as well for WASM RPC.

With the advent of FaaS and WASM based sandboxed FaaS (ex: CloudFlare Workers) and FOSS FaaS solutions in general (ex: OpenFaaS), a "native" RPC support in WASM would unlock scalable distributed computing without the limitations of the actual source programming language: C++ code bases could distribute workloads to Rust or Python code as long as the compiler/interpreted supports this WASM RPC standard. And that workload distribution would be based on:

• extern symbols, which most FFI C-compatible language already support
• but wrapped by the WASM VM to be exposed as RPCs

Another way to see it is share-nothing dynamic linking with a HTTP2 transport in the middle. Providing the benefits of modular design, while adding also the possibility for distributing the workload.

I have prototyped it by:

• using Rust's #[no_mangle] + extern "C" and a bit of custom-mangling magic (a __wasm_rpc_ prefix really) to expose the RPC functions from a Rust code base.
• Leverage wasmtime module loading to find those function symbols.
• (WIP) Start an HTTP2 server and parse the WAT/WASM function calls in the HTTP request body to actually stub them to those functions and return the result.

This PoC will desmontrate that it is possibly doable without native support in the WASM standard. But without the compiler/standard support requirement, it means:

1. An RPC-capable of some/most/any WASM VM will have to be maintained separately.
2. Since a WASM module cannot load another WASM module efficiently (ex: no JIT), the implementation of the WASM RPC transport and execution layers can - as of today - not be built/executed as a WASM module. And thus will have to be implemented/maintained in every programming language we want to support. Which defeats the whole portability of a WASM RPC implementation in the first place.

IMHO point 2 is a deal breaker. Thus my question about a potential WASM RPC standard proposal.

I would like to know if the above:

1. Makes some sense to anybody other than me.
2. Is worth investigating further to be turned into an actual spec (which would actually be mostly a subset of the WASM, WAT and Interface Type specs).

Please let me know if you have any question.