connect-es

connect-es copied to clipboard

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

Using the gRPC-Web transport locks me into using binary Protobuf serialization, which makes the network inspector fully useless.

Describe the solution you'd like

I'd like the gRPC-Web transport to support JSON serialization, like the Connect transport. This would make the network inspector only partially useless :)

Describe alternatives you've considered

I could switch to the Connect protocol, but this is a more invasive change. Why not support the same switch in both protocols?

Additional context

Originally brought up by @tannerlinsley in Slack.

Regarding the point about the network inspector, it'd be possible to build a browser extension for that :-).

Regarding the point about the network inspector, it'd be possible to build a browser extension for that :-).

Definitely possible, but difficult to do in a way that's universally usable. Converting binary protobuf to JSON requires the schema, and there's no standard for fetching a schema. (That's what Buf is building!) The gRPC reflection protocol is sort of close, but it requires bidirectional streaming....which isn't feasible from browsers.

In short, where would the browser extension get the schema from?

https://github.com/bufbuild/protobuf-es claims to support the canonical json format, so I assume it's already being generated with access to the schema. This issue is just to wire up the option, is that right?

https://github.com/bufbuild/protobuf-es claims to support the canonical json format, so I assume it's already being generated with access to the schema. This issue is just to wire up the option, is that right?

That's correct!

There is a browser extension for the official gRPC-web client: grpc-web-devtools.

It works by adding an interceptor to the the client, and sending payloads to the extension, which renders it in a dedicated inspector tab.

There are a few downsides with this approach:

• Users need to install the extension.
• The web application needs to opt in, passing a client object to a function provided by the extension.
• The extension will not show the actual network traffic, only what is visible in user land. That means you don't see headers hidden because of CORS, and have to correlate failed requests with requests in the network inspector.

For those reasons, I believe that using JSON on the wire provides a better UX than an extension, but I don't want to disregard use cases where the Connect protocol isn't an option. I think the best way forward here is to look into gRPC-web + JSON before we look into browser extensions.

I highly agree with Timo here. As someone who as built custom dev tools and felt their immediate downsides, the idea of a browser extension as the only way to see my network traffic is scary. Pushing hard for a json over the wire implementation before anything else. On Sep 20, 2022 at 1:58 AM -0600, Timo Stamm @.***>, wrote:

There is a browser extension for the official gRPC-web client: grpc-web-devtools. It works by adding an interceptor to the the client, and sending payloads to the extension, which renders it in a dedicated inspector tab. There are a few downsides with this approach:

• Users need to install the extension. • The web application needs to opt in, passing a client object to a function provided by the extension. • The extension will not show the actual network traffic, only what is visible in user land. That means you don't see headers hidden because of CORS, and have to correlate failed requests with requests in the network inspector.

For those reasons, I believe that using JSON on the wire provides a better UX than an extension, but I don't want to disregard use cases where the Connect protocol isn't an option. I think the best way forward here is to look into gRPC-web + JSON before we look into browser extensions. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

Just a quick update: We've added support for the JSON format to the gRPC-web transport a while back. It will be released in the first version that ships with the new shared package @bufbuild/connect-core, as described in the road map here.

Just checkin in on the progress here as v1 seems to have landed. Is this possible in the latest release? We are also investigating switching our backend to use the connect protocol if this isn't ready yet.

The connect-web package that uses connect-core is not yet published. Only connect-node is using this right now. We hope to have connect-web updated within the next couple weeks.

Support for JSON in the gRPC-web transport is finally available with v0.8.1 and can be enabled with a boolean option:

const transport = createGrpcWebTransport({
  baseUrl: "https://demo.connect.build",
+ useBinaryFormat: false,
});