Support dynamic input type and output type

[wenerme]

Is your feature request related to a problem? Please describe.

Trying to build a connect gateway, support post and grpc.

The proto is dynamic, generated from grpc reflect, but connect handler can not use the dynamic type due to handler code like this

request = &Request[Req]{
  Msg:    new(Req),
  spec:   receiver.Spec(),
  header: receiver.Header(),
}

I think connect-go can support dynamic pb type, the input and output type is based on reflect MessageType, maybe pass from HandlerOption, so NewUnaryHandler[any,any]() can work as expected.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

connect protocol makes grpc eaiser, but for migration, need a gateway to translate the protocol for other languages that don't speak connect protocol.

[akshayjshah]

connect protocol makes grpc eaiser, but for migration, need a gateway to translate the protocol for other languages that don't speak connect protocol.

I don't fully understand the problem you're solving - sorry! It sounds like you have a client that's using the connect-go library, and the client is configured to use the Connect protocol. Because some of your servers only support the gRPC protocol, you're trying to write a proxy to translate the Connect protocol to the gRPC protocol. Is that right?

Why not have the client use the gRPC protocol instead (using the WithGRPC client option)? Once all your servers use connect-go, you can switch the protocol that the client uses.

[wenerme]

But the client is web, do not support using grpc.

[bufdev]

connect-go supports both the gRPC-Web and Connect protocols on both the client and server, are those not sufficient?

[akshayjshah]

But the client is web, do not support using grpc.

Got it! That makes sense.

The best option is to wait a few weeks and use connect-web when we release it :) You'll get strongly-typed clients that support the Connect and gRPC-Web protocols. If you need the client to communicate with gRPC servers, you can use Envoy to translate between gRPC and gRPC-Web. When you migrate your server(s) to connect-go, you can drop Envoy - the client can talk directly to your server(s) using either the Connect or gRPC-Web protocols.

[wenerme]

So, the answer is use a grpc-web proxy?
The grpc-web proxy will loose some connect protocol features.

migrate your server(s) to connect-go

We are also using php, I think the priority of support php is very low.

[akshayjshah]

I think that the best answer is to use the gRPC-Web protocol and Envoy. You'll get the widest possible language support and a hardened, fast proxy without any custom code. That does give up many of the benefits of the Connect protocol, though.

If you'd rather use the Connect protocol and write your own proxy, nothing's stopping you! The trick is that you don't want to serialize or deserialize the messages at all - the gRPC, gRPC-Web, and Connect protocols all use standard protobuf binary encoding (or the standard protojson encoding), so you can copy the binary around without deserializing into Go structures. Naturally, this is also a lot faster than constantly using protoreflect.

You can do this by overriding the built-in proto codec like this, and then using connect.Client[bytes.Buffer, bytes.Buffer] and connect.Handler[bytes.Buffer, bytes.Buffer]. You're welcome to poke around in the bufbuild/buf/private/bufpkg/bufstudioagent directory for inspiration, but keep in mind that none of this is supported - once you copy the code, you'll need to debug and support it yourself.

Best of luck!