BareProxy 0.3.0 Writes Its Plugins in Rust, Where a Plugin Adds 15 Microseconds Instead of 42

BareProxy 0.3.0 is out. It doesn’t ship a plugin yet. It settles how the plugins get written: in Rust, with the Proxy-Wasm Rust SDK, the same one Envoy plugins use.

The question was speed. The first test plugin was written in Go, and a Go plugin carries Go’s runtime into every call. So a Rust test plugin now does everything the Go one does, and the plugin host’s tests run with both on every push. The real SDK worked with the host as it was.

What It Costs Now

A request answered by a simple rule costs about 4 microseconds on the test machine, a 2.1 GHz Xeon. Here is what a plugin adds on top:

The Go numbers dropped too, from 42 for the do-nothing case. A call into a plugin used to start a context deadline and its timer every time; now each instance keeps one timer for its time limit. What’s left in Rust is mostly the host’s own cost per call, and a request makes six calls. The design budget was 10. Rust gets closer, and isn’t there yet.

One New Config Line

SDKs export every callback, so a plugin can’t tell BareProxy which bodies it actually reads. Left alone, every SDK plugin would hold up every response body. So a plugin now gets bodies only when its config says so:

plugin rendercache /etc/bareproxy/plugins/rendercache.wasm
  body response

Without that line, responses stream past the plugin, and static files still go out with sendfile.

Where the Plugins Live

In the code repository, under plugins/. One Cargo workspace, a folder per plugin, the crates vendored so a plugin builds with no network. Each release attaches every plugin as its own .wasm file next to the binaries.

Next: the first real plugins, AI crawler control and then RenderCache. The plugins page has the program, and the binaries are on the releases page.