> Hmm, was just thinking it over, wonder if it be useful if Extism did allow flexibility in deployment (meaning that the mechanism for calls wasn't just limited to using WebAssembly to do the call/security), but could switched to using HTTP REST or GraphQL by some simple changes to some config files?
You could always deploy an actual sidecar that runs Extism -- but we believe operationally it is far simpler to eliminate other deployments and run WASM in-process as it was designed to do. But, it's certainly possible to ship Extism in many different ways :)
> ... Am also wondering if supporting both Docker and WASM might be useful/possible?
I don't think it would be practical to support Docker, unless you shipped the plugin runtime environment as a sidecar. But at that point, it's a microservice / FaaS thing. And for Docker, there are many other options that handle this well.
I think there is a really interesting middle ground that is the WASM for Proxies stuff, from Envoy, Istio, etc. Run a subset of application logic or plugins via WASM in your service mesh - I think these can terminate requests and respond directly back to the caller, acting like a microservice itself.
> You could always deploy an actual sidecar that runs Extism -- but we believe operationally it is far simpler to eliminate other deployments and run WASM in-process as it was designed to do.
Ah, yeah, actually, I can see this (focusing on just local and in process). As mentioned, 95% of the time (probably higher), it seems like sidecars are used locally anyways, so having the simplest way to use sidecars/plugins could be super beneficial. Will give Extism a try.
... and WASM for proxy type stuff sounds super interesting too:)
You could always deploy an actual sidecar that runs Extism -- but we believe operationally it is far simpler to eliminate other deployments and run WASM in-process as it was designed to do. But, it's certainly possible to ship Extism in many different ways :)
> ... Am also wondering if supporting both Docker and WASM might be useful/possible?
I don't think it would be practical to support Docker, unless you shipped the plugin runtime environment as a sidecar. But at that point, it's a microservice / FaaS thing. And for Docker, there are many other options that handle this well.
I think there is a really interesting middle ground that is the WASM for Proxies stuff, from Envoy, Istio, etc. Run a subset of application logic or plugins via WASM in your service mesh - I think these can terminate requests and respond directly back to the caller, acting like a microservice itself.