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.
The compile-time choice makes sense for a gateway: plugins sit in the hot path and often need database or queue access, which is awkward to expose through a WASM sandbox. The cost is the workflow verdverm points out: there is no prebuilt image to just pull and run. Do you plan to publish an official build with the default plugin set, for people who don't need custom plugins?
Yes, we used Claude to generate code, but we reviewed every line ourselves. For MCP, we considered rmcp, but our gateway needs hooks at each processing stage, so we would still have needed substantial custom logic. We ultimately implemented the MCP support ourselves.
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.
In Respan, plugins are not arbitrary executables that you download from a random repository. They are modular crates that you compile into your application.
Plugins offer better interface boundaries. For example, you can implement a PII feature without having to touch the logging, billing, or provider subsystems.
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.
We had a Docker image, but pulled it before launch because some APIs might still change. You have to build the Docker images, but we have GitHub releases for binaries.
We have configurable template plugins for common things like adding vendors and formats. No rebuild needed for config changes, but if you want custom logic beyond those templates, you need to compile it in.
And yes, crates still have supply-chain risks. I just meant you can review the source you’re adding, unlike a binary you don’t know.
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.
Quick question: do you personally understand the Rust code in your project, or was the whole thing AI-assisted ?
classic hackernews comments
https://github.com/respanai/respan-gateway/blob/main/apps/ga...
If we as an industry are going to p(doom) about security and hacking, perhaps we should stop doing things like this?
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.
Plugins offer better interface boundaries. For example, you can implement a PII feature without having to touch the logging, billing, or provider subsystems.
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.
We have configurable template plugins for common things like adding vendors and formats. No rebuild needed for config changes, but if you want custom logic beyond those templates, you need to compile it in.
And yes, crates still have supply-chain risks. I just meant you can review the source you’re adding, unlike a binary you don’t know.
I would recommend a batteries included approach. You can see a similar difference between adoption of OpenCode and Pi in the harness space.
And get the image published, a changing API is no reason not to have one. Every project evolves their API and users know how to handle this situation.