jhumphries131

6 ms·

1.
The Buf Reflection API and Prototransform(buf.build)
2 points by jhumphries131 4y ago|0 comments
2.
Introducing buf curl – Call your gRPC endpoints with the simplicity of buf(buf.build)
5 points by jhumphries131 4y ago|0 comments
3.
by jhumphries131 4y ago
I agree! Protoc allows comments anywhere, but it doesn't bother preserving them all in the descriptor. At one point I thought this was a bug, since comments _could_ be preserved in far greater contexts (though definitely not all). But
4.
by jhumphries131 4y ago
Gob is Go-specific. Our mission is to make schema-driven APIs easy, regardless of what language you use. Protobuf already has official support for nearly a dozen languages, and unofficial support for many more. Protobuf also has a compiler
5.
by jhumphries131 4y ago
Our aim is to make the spec accurately match Google's reference compiler -- for as long as that is the source of truth, which is hopefully not forever :) Even for those not using Buf, we expect this documentation to be of interest to t
6.
by jhumphries131 4y ago
It's possible that the internal version of protoc is very different from the open-source version. (I know there are numerous differences, but not sure how pervasive they are in the parser.) The open-source version has a hand-written to
7.
by jhumphries131 4y ago
The key "killer" use case is for describing RPC schemas. By describing the schema in an IDL, you can then generate client stubs and server interfaces in a variety of implementation languages, allowing interop between heterogenous
8.
by jhumphries131 4y ago
It is a simple language, being just an IDL (no expressions, no logic, no state, no memory model, etc). However, you might be surprised about the room for ambiguity. For example, there are several mistakes in the grammars on the official dev
9.
by jhumphries131 4y ago
Our intent with the compiler in Buf is to match protoc as perfectly as we can. We want to instill maximum confidence in our users that Buf is a trustworthy tool and a suitable replacement for protoc. And to do that, we need the behavior to
10.
by jhumphries131 4y ago
We keep an eye on the protobuf repo, so if a change is made we can both incorporate it into our products ( https://buf.build ) and into this spec. A great outcome for the ecosystem would be that Google chooses to engage with the c
11.
by jhumphries131 4y ago
A great question: We do plan to add content about the plugin protocol to this site. While documentation for plugins is light, it is easier to find and to get a working plugin than it is to find the information needed, for example, to write
12.
by jhumphries131 4y ago
As of right now, the former. That is currently required for our tools to remain functioning ( https://buf.build ). If/when changes are made to the language, we update our tools (and this spec) to continue to be accurate.
13.
by jhumphries131 4y ago
Google actually requested that the community contribute to a real specification. https://github.com/protocolbuffers/protobuf/issues/6188#issu... So we've taken the initiative. No rent-seeking.
14.
by jhumphries131 4y ago
The intent of this spec is to actually put "whatever Google did in protoc" into a readable format, so you don't have to read the C++ code. The official docs fall short on providing much of the details that are included.
15.
by jhumphries131 4y ago
Matt, that is not our intention. But we are trying to build a business around making schema-driven APIs easy, and protobuf is at the core of our current products. So we are trying to improve the ecosystem around protobuf, and a critical asp