gogoprotobuf VS googleapis

That probably won't happen either, because the Google gRPC team is also quite resistant to any kind of change (that isn't driven by internal needs at Google). Projects like GoGo Protobuf had to be developed to fill gaps that the Google team refused to fill or accept PRs for.

the gogo protobuf compiler toolchain is looking for a maintainer https://github.com/gogo/protobuf u/MehdiHK

protobuff : Google's binary data transfer protocol

Looks like Crowdstrike just pushed out publicly a replacement for gogo/proto. It looks like the library solves 2 problems:

Seems like we're pretty middle of the road. I can only guess as to why but it probably has to do with heavy usage of pointers and reflection. Gogo/protobuf solved this performance with code generation, but the go protobuf implementation has essentially eschewed it. I do wonder how the benchmark would look using the new vitess proto library for Go (which has many of the benefits of gogo but with active development and an API built on top of the Google one)

Yeah, it's a pretty thick Makefile and set of shell scripts, but it's seemingly using things like: k8s.io/code-generator/cmd/go-to-protobuf and github.com/gogo/protobuf/protoc-gen-gogo and github.com/gogo/protobuf/protoc-gen-gogofast which from what I can tell... [it looks like this can probably help me a bit in understanding how to make custom types](https://cloud.redhat.com/blog/kubernetes-deep-dive-code-generation-customresources).

repositories: # Definition depends on the 27156597fdf4fb77004434d4409154a230dc9a32 version of https://github.com/googleapis/googleapis # and defines its name as GOOGLE_APIS # It can be referenced in importPaths by $GOOGLE_APIS GOOGLE_APIS: https://github.com/googleapis/googleapis@27156597fdf4fb77004434d4409154a230dc9a32 # Definition depends on the 226206f39bd7276e88ec684ea0028c18ec2c91ae version of https://github.com/gogo/protobuf # and defines its name as GOGO_PROTOBUF # It can be referenced in the importPaths by $GOGO_PROTOBUF GOGO_PROTOBUF: https://github.com/gogo/protobuf@226206f39bd7276e88ec684ea0028c18ec2c91ae

В проекті ми використовуємо офіційну бібліотеку Protobuf github.com/protocolbuffers/protobuf, яка підчас серіалізації використовує рефлексію і будує слайс байтів через append. А потім я дізнався про "Protocol Buffers for Go with Gadgets" github.com/gogo/protobuf, бібліотеку-fork яка генерує додатковий код щоб прибрати рефексію підчас серіалізації і вже записує в слайс байтів по індексу бо так швидше. Коли змінював одну бібліотеку на іншу то важливим вважав що стало працювати швидше і написані раніше тести пройшли успішно. І все б було гаразд але в проекті існувала латка яка через пару тижнів після заміни перезапустила мікросервіс через паніку:

Rich Error Model: This model enables servers to return and clients to consume additional error details expressed as one or more protobuf messages. It further specifies a standard set of error message types to cover the most common error (QuotaFailure, PreconditionFailure, BadRequest, etc). When an error occurs, the server returns the appropriate status code along with an optional error message.

They list search in their public api

https://github.com/googleapis/googleapis/blob/288aa7fb71c9b6...

We structure the repo according to proto packages. It's quite similar to how the googleapis repository is structured.

It's unfortunate that the spec doesn't contain custom fields to a sub-object like other RPC specs, like proto Status [1]. They should have had the message go into a field named "message" and not "detail". And have a field like "details" where the opaque type is serialized, which should be named by the "type" field. The problem is that systems with existing error types may have field name conflicts with type, title, status, detail, or instance, so we'd just dump the actual error into a custom "extension member" which by definition, isn't standard.

[1] https://github.com/googleapis/googleapis/blob/1c8a25ab153eef...

Protobuf (https://github.com/googleapis/googleapis)

All the required changes can be viewed in our last demo, the grpc-rest-app implementation. First, we need to update our proto service interface to help the proxy service make our gRPC service methods available at the right URLs and for the correct HTTP operations. To do this, the Google API HTTP library provides annotations we can add to our proto to describe the correct mappings. The buf tool allows us to include the googleapis dependency as a plugin in our buf.yaml file).

I think this only makes sense if the 3rd party is also throwing custom exceptions.

If you want to reduce coupling you should avoid throwing custom exceptions at all. Semantic information can go in the error message and log. The error type should be used to indicate to your program whether an error is recoverable, retriable or some other action needs to be taken. For example google on has 16 canonical error codes for all APIs.

https://github.com/googleapis/googleapis/blob/master/google/...

OpenAPI and possibly developing reusable, versioned client libraries could help, but it's a major undertaking that gRPC makes redundant. I'd be tempted to use grpc-gateway even if I had to implement a REST API. Try looking into buf and monorepo structures for proto management, e.g. something like GoogleCloudPlatform/microservices-demo. For more thorough proto and grpc-gateway definition examples, see googleapis/googleapis.

Firestone does provide global consistency, so the following quote is incorrect:

> In Cloud Firestore, the data on the client are loaded from the database at different points in time. Even if you listen for realtime updates, results from separate queries will not remain in sync. This creates consistency anomalies and bugs in your app.

Here is a link to the protocol documentation that the clients use to support it: https://github.com/googleapis/googleapis/blob/d0b394f188e8c3...

I'd link to the client implementation but it's quite involved.

Well there is Timestamp defined as a well known type which is available to all implementations despite not being a primitive type [1]. Plus one is obviously able to define any other custom types if necessary- eg as seen in [2].

[1] https://developers.google.com/protocol-buffers/docs/referenc...

[2] https://github.com/googleapis/googleapis/blob/master/google/...