Yes, the usage of Wasm for filters makes a lot of sense. This is why I previously mentioned the Envoy’s proxy-wasm spec<https://github.com/proxy-wasm/spec>, which is essentially an ABI specification for running WebAssembly in proxies. Beyond Envoy, you can find similar approaches in Nginx<https://wasmedge.org/book/en/use_cases/frameworks/mesh/wasm-nginx-module.html> and in APISIX<https://github.com/apache/apisix/blob/master/docs/en/latest/wasm.md>. One of our long term goals is to implement this specification for Apache itself.
mod_wasm’s initial goal is to allow running unmodified apps under WebAssembly in Apache (i.e.: WordPress, Drupal, etc.). Having said that, it is also a great fit to expose the internal Apache APIs, enabling safely building Apache modules using ANY language, not just filters but any functionality. Basically, a lot of the functionality you need to use mod_lua and mod_perl (or having to write your own C module) but language independence and with other benefits inherited by running Wasm code: sandboxing security, running at almost native, etc.
