bufbuild

Totally, and we appreciate the sentiment. But the title was meant to be lighthearted, and instead it clearly struck a nerve. That's not our intent, and it was easy to change, so we just swallowed our pride. We rather the conversation be around Protobuf tooling, and not our poor comedy.

And the Buf CLI will always be free and OSS, don't worry!

We're terrible comedians - we've added something of a mea culpa to the post!

Fair enough - feedback taken, we don't have a second career in comedy! Appreciate the feedback - we're renaming the post once GitHub is back online, and are adding the following to it for transparency:

> Edit: In full transparency, this blog post was originally titled "Protobuf finally has LSP support. You're Welcome." We thought this might generate some interest, but unfortunately this post sat unloved for months. Then, out of the blue, this post decided to make front page HN, and we received some choice feedback on our use of "You're Welcome" and our poor comedic abilities. Fair enough, we appreciate you speaking up - and we of course *thank you* for your continued support of our work!

> No clear and easy way to use it with HTTP/1.1. Neither is specific to Python.

> It seems like Google focused on gRPC, but the real prize for adoption would've been going after the simple HTTP+JSON use cases. Like an official protobuf Express middleware.

We'd flag https://connectrpc.com for you :-) HTTP/1.1 out of the box, switches on Content-Type between binary and JSON, and fully-compatible with gRPC. cURL with JSON just works.

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...

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

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

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

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.