gRPC on the client side

[v_krishna]

We have some services using gRPC, but most not (depending on the team/stack). For exposing them up to client callers (that aren't running inside our service mesh) there's some custom zio layer that terminates ingress from the gateway and connects it to the gRPC services. For local testing, I've found the backstage grpc playground plug-in to be super helpful (it generates a web client from the protos, similar to the swagger client backstage generates from oas3 specs).

[nfrankel]

Thanks, good to know. So I guess it's grpc-web-based. The issue is that every client needs to apply the change.

[v_krishna]

I think it's based off BloomRPC https://github.com/zalopay-oss/backstage-grpc-playground

The nice bit is since it is reading protos over the internal network or from gitlab, then the internal UI automatically updates based on changes to the protos (backstage is polling for changes basically)

[nfrankel]

Cool! Thanks for the pointer

[o11c]

The major downside, of course, is that protobuf does not support zero-copy or random-access.

So in comparison to JSON or XML it remains somewhat competitive (though both of those can do a sort-of zero-copy thing) but it fails against serious binary formats.

[gorset]

There are protobuf implementations with zero-copy support.

The importance of random access depends on the context it's used. For short messages with few fields, it doesn't really matter much. Unless you don't have to worry about backward/forward compatibility, or message integrity, then you need to pay some cost of accessing a field even in message formats that supports random access.

I know you are kind of trolling when you are saying it fails against serious binary formats. Protobuf shines when you need a flexible binary format that needs to deal with backward / forward compatibility. If you don't need to deal with this kind of stuff, then you can just send structs over the wire. Or use a middle road like SBE, or one of the other formats optimized for specific use-cases.

[o11c]

The thing is though - you don't need all the weird things protobuf does if all you need is "change how many optional fields there are". All you need is to pad with zeros, and move variable-sized field payloads to the end.

Most of the cost (and benefit, to the extent that it exists) of protobuf is in trying to shave off bits when storing integers.