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.
