Pluggable protocols

[rauanmayemir]

This is to kickstart a discussion about making client and server protocols pluggable.

I have goals to transcode client soap protocol into grpc server protocol, but vanguard won't let me plug my implementation in, and a lot of protocol conversion is private. Exposing crucial steps as public interfaces would allow for customization.

So while vanguard can enforce interfaces and give base implementations, client or server protocol adapters could be extended or replaced.
Currently, even a slight adjustment to a client or server protocol would require a lot of duplication to a point where a fork would be easier way to go.

I'm wondering if this is a potential direction vanguard could grow in.

[jhump]

I don't expect we're likely to grow vanguard in this way. It isn't meant to be a general-purpose, pluggable protocol translation library.

The (unexported) abstractions that exist for the protocol translation are a bit specific to ConnectRPC, gRPC, and gRPC-Web, which have similar protocols and nearly identical framing for streaming behavior. And they are a bit complicated as-is (largely for the wrinkles that REST adds). Making them even more generic would make them even more complicated. Exposing user-friendly abstractions would be non-trivial API design work, and it would also be a challenge to solve the tension between easy-to-use/easy-to-implement abstractions and efficiency/performance. Vanguard's purpose was to fit in places where gRPC-Gateway or Envoy's gRPC-JSON transcoding plugins might be used, but to provide a better operational story (no extra code generation steps; could build a proxy that doesn't require artifacts to be re-generated or re-deployed when the schema changes). And it was also a stepping stone for customers that want to migrate from gRPC to Connect, by allowing clients to use the Connect protocol but leave servers using gRPC code (with Vanguard in between to translate Connect->gRPC).

So taking this project in this direction feels like a fairly heavy lift, and its value/benefit seems unclear. (I certainly see the value in your use case, but we can't take on so much effort if it benefits very few.)

One thing we have been discussing is creating a separate "connect-protocol" library, that has lower-level helpers for reading and writing the protocols' wire formats. This could be used both by this library and by the main connect-go repo. And such a library could then also be used for your use case: to build a bespoke protocol translation, where you aren't having to "reinvent the wheel" for handling the ConnectRPC/gRPC/gRPC-Web side of the transformation.

[rauanmayemir]

Looks like I understood vanguard's purpose well. I migrated most of our services which used to require codegen for descriptor sets and L2 envoy to transcode, but now it's bundled into my backend.

[nicksnyder]

Given we have no plans to support pluggable protocols, I am going to close this issue.