If so, then super interesting product! Have actually had a somewhat similar idea myself for a product that allows you to create "subsystems" that are isolated from one another, allowing you great freedom in how the subsystems are deployed. They could be deployed all on the same machine, or, if greater scalability is needed, a subsystem (or plugin) could be moved to its own machine, or even scaled up to run multiple instances.
Have only read through the simple code example on your website, but also, it would be great if there was a standard for calling and receiving requests through FFI's. Because this would give it the utmost flexibility on where the plugins can be deployed to. To me, this means both the actual mechanism for the call (REST over HTTP, graphQL...) and in the plugin and host themselves, with the syntax of the call. So for the syntax, it would also be great if this looked more like a regular method call instead of having to wrap parameters in an object:
hostWrapper.somemethod(param1, param2) or
hostWrapper.call("somemethod", param1, param2)
(Although, not sure how difficult this is to do, given all the different method call syntaxes of the different languages).
And, am glad that you and your company is really trying to make this happen, it's a great idea! Looking forward to giving it a try!
it's not quite the sidecar pattern (assuming i'm interpreting the link you shared correctly) - since Extism is actually _embedded_ into your program's process, not isolated over a network boundary like a sidecar.
the benefit of this is typically much faster execution speed, and thanks to WebAssembly's security model, it's safe to execute plug-in code - unlike a DLL or dlopen to a .dylib or .so file. in effect, it becomes an actual function call, not a RPC.
please correct me if i've misinterpreted your post!
Think you interpreted the Side Car pattern pretty well:) It definitely is typically done using HTTP (REST), and the benefit of this is it gives it great flexibility, allowing it to be deployed in many different ways.
Like Extism, sidecars are typically developed in some type of container like Docker (I have a limited understanding of WASM but since it's also a container technology, think you could also use this instead). And since the calls into the container are done through a standard like HTTP REST (or GraphQL), it's no problem if you'd like to have the container deployed locally, or on the same machine as your host container, or even on it's own server if you need to run it as its own microservice.
Although typically, sidecars are deployed locally and work almost exactly like Extism - simply as a plugin to the main application. And the performance of the local call is pretty good, because the call is usually made over a virtual network you'd setup in your docker configuration files.
I came across sidecars for the first time a couple of years ago while doing a job at Atlassian. And, for me, creating an entire product like Extism to take plugin/sidecars to the next level seems like a great idea. Because sidecars are awesome and we need a way to make them easier and easier to develop!
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? Because now the plugins can be deployed in many different ways, and even work in legacy systems (they may have their own security model. Seems like some type of REST security is pretty popular)...
... although, as mentioned, from what I saw, seemed like 95% of the time, sidecars are used locally as well, like Extism, so maybe just focusing on local calls is good enough??
... Am also wondering if supporting both Docker and WASM might be useful/possible?
And of course, I have very limited understanding of Extism, so of course, I may be waay off in what the future directions of your product, so please take everything I said with a grain of salt. But, Extism does seem like a great idea! Will give it a try.
> 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:)
If so, then super interesting product! Have actually had a somewhat similar idea myself for a product that allows you to create "subsystems" that are isolated from one another, allowing you great freedom in how the subsystems are deployed. They could be deployed all on the same machine, or, if greater scalability is needed, a subsystem (or plugin) could be moved to its own machine, or even scaled up to run multiple instances.
Have only read through the simple code example on your website, but also, it would be great if there was a standard for calling and receiving requests through FFI's. Because this would give it the utmost flexibility on where the plugins can be deployed to. To me, this means both the actual mechanism for the call (REST over HTTP, graphQL...) and in the plugin and host themselves, with the syntax of the call. So for the syntax, it would also be great if this looked more like a regular method call instead of having to wrap parameters in an object:
(Although, not sure how difficult this is to do, given all the different method call syntaxes of the different languages).And, am glad that you and your company is really trying to make this happen, it's a great idea! Looking forward to giving it a try!