We are updating plugins interface, adding wasm support (along with current go.plugin) and much more in 1.4.0

[akshaydeo]

👋 Bifrost plugins have been getting a fair bit of use across both OSS and Enterprise setups, and we’ve been collecting a lot of feedback around where the extension model works well and where it’s too rigid.

We are now adding middleware support in plugins

• Your plugins can inject now HTTP middlewares in Bifrost. This opens up a lot of possibilities for extending the functionality of Bifrost.
• Under the hood, this is exposed as a BifrostHTTPMiddleware type on the plugin interface, which wraps a fasthttp.RequestHandler. Your plugin can return a middleware that runs in the same chain as the built-in bifrost-http middlewares and gets access to the raw request/response at the transport layer, before it is converted into a BifrostRequest. This is useful for things like auth checks, header normalization, simple routing decisions, or low-level logging/metrics that you want to do before any provider or governance logic kicks in.

Here is the first PR.

We are supporting WASM based dynamic plugins too

• We started with support for go.plugins as its the fastest option to dynamically extend the functionality of Bifrost. The overhead is in nano-seconds and the way we have integrated it, it stays in single digit nano-seconds. But this comes at a cost of making sure that your plugin is using the exact same versions of the packages Bifrost is using. And of-course you have to write them in Go.

  • Concretely, these plugins are built against the same core/schemas package and loaded in-process, so they share the same types and memory space as Bifrost itself. That’s why they are so fast, but also why Go version and module versions have to match what the Bifrost binary is built with.

• By supporting WASM, you can write dynamic plugin in any language and generate WASI compatible WASM. And we would be able to run them.

• The idea here is to treat the WASM module as a dynamic plugin that implements the same logical lifecycle (init, configuration, request hooks) but compiled to WASI instead of a Go plugin. As long as your language can target WASI, you can implement the plugin logic there, and Bifrost will load and execute it via a WASM runtime. This gives you a way to keep your plugin code in Rust, Zig, C, TinyGo, etc., without being tied to Bifrost’s Go module graph.

Note

We are dropping first preview of this plugin system in 1.4.0. The initial release will be marked as a preview so that we can stabilize the ABI and configuration format based on real use cases. Expect the basic wiring to be in place (loading WASM modules, passing configuration, and calling into them on the plugin hooks), but details like the exact data structures and limits may change between early 1.4.x builds. Feedback on concrete workloads you want to run inside WASM will directly shape how this evolves.