Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pluggable protocols #159

Open
rauanmayemir opened this issue Jan 30, 2025 · 1 comment
Open

Pluggable protocols #159

rauanmayemir opened this issue Jan 30, 2025 · 1 comment

Comments

@rauanmayemir
Copy link

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
Copy link
Member

jhump commented Jan 30, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants