Thanks for the question! The plugins are natively compiled Rust crates, not interpreted or dynamically loaded.
We considered WASM and libloading. For WASM, plugins often need access to infrastructure such as databases, which would require additional host interfaces and runtime support.
Dynamic loading with libloading didn’t offer enough benefit for this design, so we chose modular crates compiled into the application.
Why are plugins a desirable feature for core features?
Today I use GoModel, and in example, all providers are built in. Having recently given Pi a try, the plugin ecosystem is a mess and I have more security worries.
Can you explain why you think a plugin based system is preferable to a competent team building a complete, curated product?
Plugins seems like a great way to expose yourself to supply chain security events.
Hi, I hear your concerns, and we can clarify how this works.
In Respan, plugins are not arbitrary executables that you download from a random repository. They are modular crates that you compile into your application.
The benefit of this system is that it provides explicit processing boundaries. For example, a PII filter can register for relevant events without requiring changes across tangled client, provider, logging, and translation paths. This also makes it easier to compose features.
So we cannot just run a docker image for a gateway, we will also need an entire CI process to use this paradigm? Generally, when we use the term "plugin" in industry, this means we do not have to run a compiler.
Crates are still an avenue for supply chain compromise, they come from random developers. We've seen it before and I expect we will see in more frequently for a while, until out industry gets really serious about all the things around this.
What's your plugin model for Rust? Are they compiletime or interpreted?
Thanks for the question! The plugins are natively compiled Rust crates, not interpreted or dynamically loaded.
We considered WASM and libloading. For WASM, plugins often need access to infrastructure such as databases, which would require additional host interfaces and runtime support.
Dynamic loading with libloading didn’t offer enough benefit for this design, so we chose modular crates compiled into the application.
Good luck with the launch!
Quick question: do you personally understand the Rust code in your project, or was the whole thing AI-assisted ?
"do you personally understand the code"
classic hackernews comments
Why are plugins a desirable feature for core features?
Today I use GoModel, and in example, all providers are built in. Having recently given Pi a try, the plugin ecosystem is a mess and I have more security worries.
Can you explain why you think a plugin based system is preferable to a competent team building a complete, curated product?
Plugins seems like a great way to expose yourself to supply chain security events.
Hi, I hear your concerns, and we can clarify how this works.
In Respan, plugins are not arbitrary executables that you download from a random repository. They are modular crates that you compile into your application.
The benefit of this system is that it provides explicit processing boundaries. For example, a PII filter can register for relevant events without requiring changes across tangled client, provider, logging, and translation paths. This also makes it easier to compose features.
So we cannot just run a docker image for a gateway, we will also need an entire CI process to use this paradigm? Generally, when we use the term "plugin" in industry, this means we do not have to run a compiler.
Crates are still an avenue for supply chain compromise, they come from random developers. We've seen it before and I expect we will see in more frequently for a while, until out industry gets really serious about all the things around this.