Connect libraries are 100% compatible with gRPC - in many cases, they implement the gRPC spec more faithfully than the core libraries themselves: https://buf.build/blog/grpc-conformance-deep-dive

TLDR: there should be no migration cost.

It's worth checking out our take on a lot of these problems: https://buf.build/blog/connect-web-protobuf-grpc-in-the-brow...

Yea I'm aware of that. I wish you guys the best of luck. I tried a lot of this with Micro. I think it's the right direction especially if you can simplify the tooling. The hard part is just the adoption curve but I think you have a lot of funding to find your way through that.

protobuf-es does as well! https://github.com/bufbuild/connect-web

Its totally not obvious if this is usable for a non "connect" server side implementation (Grpc.net etc)?

That is for the text format, which is a serialized representation of Protobuf data. As they specify in the linked doc, it is not the format for the actual language:

> This format is distinct from the format of text within a .proto schema.

Of course, also check out Connect :-) https://connect.build

> Simple, reliable, interoperable.

I like that.

The URI is per-RPC, specifically at /service/method, if that helps.

On cacheability, do check out https://connect.build/docs/protocol#future-extensions - it’s something we continue to put thought into to make sure we get it right.

And there’s Buf Studio :-) https://buf.build/blog/buf-studio https://studio.buf.build

We’d really recommend checking out the Connect protocol in this case - we totally understand that a new custom protocol would induce a few eye rolls, but it’s about as simple as it gets, especially with unary - it’s just HTTP POST at /service/method, switching on Content-Type between application/json and application/proto (for JSON vs binary payloads). All your existing tooling for HTTP observability should mostly “just work”. https://connect.build/docs/protocol

I love the idea of a more http-native protocol, and I think ya'll are doing saintly work, and I hope observability tools close remaining gaps fast.

I still think we're a little short on candor though. Streams are a bitch in grpc. I have a very very hard time believing plain-old http observability is going to be good enough to help me make sense of multiple cross-directional streams stemming from a single request. gRPC just has a lot to it. Being more plain http-centric is applause worthy. But grpc has too much going on for plain http support to be enough, when it comes to really pleasant observability & tooling.

I dont want to discourage but I dont see how we could expect tl have near as good an experience as what great real grpc tooling supports. I love these workarounds to browser enable, but they have real tradeoffs & sacrifices. That alas the browser hss forced us all into by it's utter lack of giving a shit, caring, doing anything good with making http useful to us.

It already does! The connect protocol supports all streaming mechanisms.

The beauty of the Connect ecosystem is that no proxies are required - the Connect protocol works just as well from the browser as it does on the backend.