Launch HN: Respan (YC W24) – Open-source Rust AI gateway built around plugins
35 pointsby Andydy257 hours ago4 comments
  • blakeashleyjr6 hours ago
    What's your plugin model for Rust? Are they compiletime or interpreted?
    • Andydy256 hours ago
      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.

      • rileycalhoun0225 hours ago
        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?
        • Andydy255 hours ago
          We do have an official build on GitHub Releases with first-party plugins built in.
  • m00dy6 hours ago
    Good luck with the launch!

    Quick question: do you personally understand the Rust code in your project, or was the whole thing AI-assisted ?

    • Andydy256 hours ago
      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.
    • bb-connor6 hours ago
      "do you personally understand the code"

      classic hackernews comments

  • verdverm6 hours ago
    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.

    [1] https://gomodel.enterpilot.io/

    • Andydy256 hours ago
      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.

      • verdverm6 hours ago
        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.

        • Andydy255 hours ago
          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.

          • verdverm5 hours ago
            No one at our org knows rust, so "reading the source" is not possible, and we know people don't actually do this anyway.

            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.

        • Andydy255 hours ago
          Yeah, ours are more like GStreamer’s statically compiled plugins. We might consider WebAssembly in the future if there’s a need for it.
  • skorohodhelgaan hour ago
    [dead]