apollo-client-devtools VS Protobuf

This call creates canonical field allTodos on the root Query type. We can confirm this by opening apollo devtools and viewing the 'cache' tab.

People don't understand how their code can mess up others in unexpected ways. A few weeks ago my youtube just stopped working. Turns out, a change made to the apollo-graphql extension caused window.process to be readonly and youtube's code was not expecting that: https://github.com/apollographql/apollo-client-devtools/issu...

I know this isn't a dependency issue, but it's a great example of why things like semver don't work perfectly in practice. It's hard to figure out what the effects of your code really are in the end. You might assume a change is minor when it really is major. I wish programming languages could figure out what the version change should be for a given code change.

Do you perhaps use chrome and have apollo client dev tools installed? They break import maps, which breaks the site, see here: https://github.com/apollographql/apollo-client-devtools/issues/464

It's so weird that this seems like a common use case but across the 3 channels I've asked (also asked on the official Apollo Spectrum chat & SO) it's radio silence beyond your reply! To add insult to injury, Apollo devtools was updated over the weekend and broke for v2 clients! Argh!!

protobuf: go get -u google.golang.org/protobuf/proto

It's because they changed the versioning format: https://github.com/protocolbuffers/protobuf/releases?page=5

But I suppose old version still receive bugfixes.

For at least 4 years protobuf has had decent support for self-describing messages (very similar to avro) as well as reflection

https://github.com/protocolbuffers/protobuf/blob/main/src/go...

Xgooglers trying to make do on the cheap will just create a Union of all their messages and include the message def in a self-describing message pattern. Super-sensitive network I/O can elide the message def (empty buffer) and any for RecordIO clone well file compression takes care of the definition.

Definitely useful to be able to dig out old defs but protobuf maintainers have surprisingly added useful features so you don’t have to.

Bonus points tho for extracting the protobuf defs that e.g. Apple bakes into their binaries.

gRPC Gateway is a protoc plugin that reads gRPC service definitions and generates a reverse proxy server that translates a RESTful JSON API into gRPC.

To use more recent versions of protoc in future applications, you can download them from the Protobuf repository.

Use the Protobuf CLI protoc and the plugin protoc-gen-tonic.

> didn’t find any standard for separating protobuf messages

The fact that protobufs are not self-delimiting is an endless source of frustration, but I know of 2 standards:

- SerializeDelimited* is part of the protobuf library: https://github.com/protocolbuffers/protobuf/blob/main/src/go...

- Riegeli is "a file format for storing a sequence of string records, typically serialized protocol buffers. It supports dense compression, fast decoding, seeking, detection and optional skipping of data corruption, filtering of proto message fields for even faster decoding, and parallel encoding": https://github.com/google/riegeli

It looks like it is in fact universal. Just glancing at the code here, it looks like the tool searches any arbitrary file for bytes that look like encoded protobuf descriptors, specifically looking for bytes that are plausibly the beginning of a FileDescriptorProto message defined here:

https://github.com/protocolbuffers/protobuf/blob/main/src/go...

This takes advantage of the fact that such descriptors are commonly compiled into programs that use protobuf. The descriptors are usually embedded as constant byte arrays. That said, not all protobuf implementations embed the descriptors and those that do often have an option to inhibit such embedding (at the expense of losing some dynamic introspection features).