Why are plugins a desirable feature for core features?
Today I use GoModel [1], 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.
The plugins are natively compiled Rust crates, not interpreted or dynamically loaded.
We considered WASM and libloading, but plugins often require database connections or other privileges. With WASM, supporting that would be the SDK’s responsibility.
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.
verdverm | 6 hours ago
Today I use GoModel [1], 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.
[1] https://gomodel.enterpilot.io/
[OP] Andydy25 | 5 hours ago
Plugins offer better interface boundaries. For example, you can implement a PII feature without having to touch the logging, billing, or provider subsystems.
verdverm | 5 hours ago
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.
[OP] Andydy25 | 5 hours ago
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.
verdverm | 5 hours ago
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.
[OP] Andydy25 | 5 hours ago
blakeashleyjr | 6 hours ago
[OP] Andydy25 | 5 hours ago
We considered WASM and libloading, but plugins often require database connections or other privileges. With WASM, supporting that would be the SDK’s responsibility.
Dynamic loading with libloading didn’t offer enough benefit for this design, so we chose modular crates compiled into the application.
rileycalhoun022 | 5 hours ago
[OP] Andydy25 | 5 hours ago
m00dy | 6 hours ago
Quick question: do you personally understand the Rust code in your project, or was the whole thing AI-assisted ?
bb-connor | 5 hours ago
classic hackernews comments
verdverm | 5 hours ago
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?
[OP] Andydy25 | 5 hours ago