Comment by rektide | Hacker News Reader

Comment by rektide | Hacker News Reader

Parent Full thread

But your services have to support the Connect protocol. You can also ship services that support gRPC-Web directly too & run without a proxy.

This is definitely a step up, nicely convenient. But also, it has downsides too. gRPC is incredibly well supported by a huge number of observability tools and service-layers/service-mesh systems. Few have support for gRPC-Web. Which if any have support for Connect-Web?

In general, it's just massively sad that the browser never got around to making HTTP Push useful for protocols. gRPC should have been positioned to do great things, was a very common-sense overlay atop HTTP2 that provided just a little more semantics to say how things ought work. It triangulated nicely on where we were going, at it's inception, back in 2014/2015. But the browser basically never evolved, never gave developers access to do the good stuff we thought we'd start to have access to. I still see brand new specs that shout out to the Low Level Extensibility Manifesto[1], but for some reason, in terms of the most base layer of the web, HTTP, this simple guidance has been roundly ignored & the capabilities were never delivered. So gRPC has been stuck with a pretty ok protocol, & frustratingly discompatible browser.

[1] https://github.com/extensibleweb/manifesto

Yeah this is the deal breaker for me as well. This smells like an embrace-extend-extinguish campaign frankly?

1. Embrace gRPC and protobuf 2. Extend with Connect, get everyone using this in their APIs and web apps 3. Drift away from established gRPC and/or protobuf standards, build platforms/business around this and trap as many folks as possible

As silly as it may seem, one thing that really sends this signal for me is the nice trademark symbol on the Buf name. their intention for all of this stuff is to build a business.

In many ways, you're spot on. We are trying to build a business: a schema registry for Protobuf. We think that schema-driven APIs makes a lot of sense, that Protobuf is the de facto best schema language, and that the biggest gap is good tooling to share and leverage the schemas.

To retire in Scrooge McDuck-sized vaults of gold,* though, we need to make Protobuf super awesome so that individual developers and companies are willing to use it. It's not super-awesome today, and gRPC is often even worse. To everyone's benefit (I hope), we have the funding and runway to tackle this problem.

From our perspective, your plan looks more like:

(1) Meet everyone where they are, which is mostly Protobuf v3 and gRPC. Adopting a new implementation of a standardized wire protocol in some portion of your system is risky, but not crazy.

(2) Offer a graceful upgrade path to an RPC protocol we think is better, and genuinely solves many pain points with the current status quo.

(3) If we're wildly successful, influence the Protobuf language community whenever a v4 is under discussion. There are certainly warts to fix and nice features to add, but stability and widespread support have a powerful magic of their own.

Good intentions are hard to prove, of course. Hopefully releasing good, well-supported OSS code can be a first step in building some trust.

* Kidding about the piles of gold. I wouldn't say no, but this is the most fun I've had at work in a decade :)

Personally, I hope you guys succeed. I’m planning to switch to buf, connect-go etc — despite the yaml config files…

> Which if any have support for Connect-Web?

As far as I can tell it's just HTTP, so... all of them?

gRPC is also just HTTP too, yet these tools go much much further to provide good observability of the specific gRPC transactions happening over HTTP. With this application level protocols flowing atop the hypertext transfer protocol, being able to reach in & see what the app protocol doing is invaluable for observability. So no, just about none of these tools will have actually good Connect-Web support. Being able to see streams, parameters, a host of other capabilities is unlikely to just work fine.

Unless you're all-in on server streaming, the Connect protocol is indistinguishable from RESTful HTTP to this class of L7 proxies - it's just a POST to a Protobuf-looking path, with an `application/json` or `application/proto` Content-Type. Most of the proxies/service mesh things that provide rich gRPC instrumentation are also capable of providing rich instrumentation for this style of HTTP.

I dunno. I'd like to see some comparisons. HTTP is so broad. Observability tools do good with it. But I think it's deceitful & disingenuous to blow this topic off like this.

Streams use features like HTTP2+ Push, & there's all manner of semantic meaning implicit in headers & schemas that regular http wont see that these tools pick up on. I want to be sold that the complex multi-directional multi-stream works fine, are fully observable, but I suspect seriously we're overreducing, not being honest, by discarding the difficulties of tuning observability to specific protocols here & saying general http support will buy us everything.

I'm honestly confused as to what your gripe is. I've done it all, OpenAPI, graphql, gRPC -- what exactly is difficult observability wise? Can you provide some specifics as to what is problematic?

HTTP is broad, and some things are easier to observe than others. Something like streaming or websockets is by definition more complex than the most basic possible HTTP request/response. Your complaint boils down to "using features makes observability difficult", which is obviously true in some sense, but you're dismissive of what those features unlock.

You must despise graphql.

Reply on news.ycombinator.com