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.
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 :)
As far as I can tell it's just HTTP, so... all of them?
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.
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.
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