Question: Using the connect protocol for requests to a gRPC-Go backend

[alexandros-megas]

Hello,

At clarifai, we're already using grpc to expose our API using the native binary protocol. As I understand it, our backend team is using the golang grpc library from https://pkg.go.dev/google.golang.org/grpc to expose the service.

I'm evaluating the connect-web toolkit for building a typescript browser client for my team's front end react app, and I have to say so far I'm really loving the fact that the code it generates is MUCH more idiomatic than what grpc-web produces.

I'd like to know if a connect-web TS client, using the connect transport, can send requests to such a backend, or would we have to make changes to our backend in order to accept/respond to requests from a connect transport. I was looking at your homepage at https://connect.build, and noticed the following, which suggests the connect protocol can interop with native grpc servers, but maybe I'm misreading it?

In addition to its own protocol, Connect servers and clients also support gRPC — including streaming!
They interoperate seamlessly with Envoy, grpcurl, gRPC Gateway, and every other gRPC implementation.

[timostamm]

Hey Alexandros,

connect-go implements three protocols: gRPC, gRPC-web, and Connect (the protocol).
connect-web implements two protocols: gRPC-web and Connect. gRPC-Go (your backend) implements one protocol: gRPC.

Since your backend is using gRPC-Go, connect-web cannot communicate with it out of the box. (The gRPC protocol relies on HTTP trailers, and web browsers do not expose them in userland).

It looks like we need to clarify this in the copy on the homepage. I think this wasn't updated completely when we launched connect-web. Apologies.

There are a couple of options:

1. Use a proxy to translate between gRCP and gRPC-web. Envoy is mature and commonly used.
2. Switch from gRPC-Go to connect-go.

Both options maintain gRPC compatibility, while adding support for an additional protocol. The main difference between the gRPC-web protocol and the Connect protocol is that Connect is more HTTP friendly, can be used with curl, and uses human-friendly JSON on the wire.

It might be a different story in your case, but for some teams, connect-go was just what they were waiting for. We're happy to help with more details. We have an active community on slack, in case you are interested.

[alexandros-megas]

Thanks for the reply and clarification, @timostamm!

That makes sense to me. I will run this up the chain of command, and try to get more stakeholders on board, because we're currently using grpc-web/google-protobuf for our React browser app, which is less than ideal. Our goal is to get rid of the grpc-web proxy and connect-go/connect-web seems like the ideal way to do that.

[alexandros-megas]

Followup question: Am I correct in thinking that connect-go implements multiplexing of the various protocols it implements? Ideally we'd like to support, at a minimum, grpc (for our API client customers) and connect (for our own frontend, and presumably any of our users who want to connect via their browser app)

[timostamm]

That is correct, connect-go does support "multiplexing".

For example, the API for our schema registry serves the Connect protocol:

curl \
    --header 'Content-Type: application/json' \
    --data '{"query": "e", "pageSize": 10}' \
    https://api.buf.build/buf.alpha.registry.v1alpha1.SearchService/Search

But you can just as well hit the same endpoint with gRPC or gRPC-web clients.

[timostamm]

Closing this, as I think the question is answered. @alexandros-megas, let us know if we can help going forward. We also have an active Slack workspace.

[akshayjshah]

Closing this, as I think the question is answered. @alexandros-megas, let us know if we can help going forward. We also have an active Slack workspace.

If you connect with us on Slack, we're also happy to chat in detail or arrange a conversation with any internal stakeholders.