gRPC: The Bad Parts

Post by hot_gril » Thu, Jun 27, 2024, 5:59 PM UTC

anon291 wrote: post #36

leetharris wrote: post #18

Earlier quoted context omitted.

> At any rate just use JSON with WebSockets. Its stupid simple and still 7-8x faster than HTTP with far less administrative overhead than either HTTP or gRPC. gRPC is not supposed to be a standard web communication layer. There are times where you need a binary format and extremely fast serialization/deserialization. Video games are one example where binary formats are greatly preferred over JSON. But I do agree that…

Depending on the use case, it's often better to just copy structs directly, with maybe some care for endianness (little-endian). But at this point, the two most popular platforms, ARM and x86, agree on endianness and most alignment. There's almost no reason why RPC should not just be send(sk, (void *)&mystruct, sizeof(struct mystructtype), 0)

Post by pixl97 » Thu, Jun 27, 2024, 6:01 PM UTC

neonsunset wrote: post #54

bunderbunder wrote: post #49

All good points. But I'd argue that the single worst part of gRPC is the impenetrability of its ecosystem. And I think that, in turn, is born of complexity. The thing is so packed with features and behaviors and temporal coupling and whatnot that it's difficult to produce a compatible third-party implementation. That means that, in effect, the only true gRPC implementation is the one that Google maintains. Which, in…

It is possible to do quite well, as demonstrated by .NET. Edit: and, if I remember correctly, gRPC tooling for it is maintained by about 1-3 people that are also responsible for other projects, like System.Text.Json. You don't need numbers to make something that is nice to use, quite often, it makes it more difficult even.

Post by jamesmunns » Thu, Jun 27, 2024, 6:02 PM UTC

anon291 wrote: post #36

leetharris wrote: post #18

Earlier quoted context omitted.

> At any rate just use JSON with WebSockets. Its stupid simple and still 7-8x faster than HTTP with far less administrative overhead than either HTTP or gRPC. gRPC is not supposed to be a standard web communication layer. There are times where you need a binary format and extremely fast serialization/deserialization. Video games are one example where binary formats are greatly preferred over JSON. But I do agree that…

Depending on the use case, it's often better to just copy structs directly, with maybe some care for endianness (little-endian). But at this point, the two most popular platforms, ARM and x86, agree on endianness and most alignment. There's almost no reason why RPC should not just be send(sk, (void *)&mystruct, sizeof(struct mystructtype), 0)

Post by anon291 » Thu, Jun 27, 2024, 6:02 PM UTC

hot_gril wrote: post #61

anon291 wrote: post #36

Earlier quoted context omitted.

Depending on the use case, it's often better to just copy structs directly, with maybe some care for endianness (little-endian). But at this point, the two most popular platforms, ARM and x86, agree on endianness and most alignment. There's almost no reason why RPC should not just be send(sk, (void *)&mystruct, sizeof(struct mystructtype), 0)

Won't work if your struct has any pointers in it.

Post by fisian » Thu, Jun 27, 2024, 6:03 PM UTC

dudus wrote: post #43

mattboardman wrote: post #41

My biggest complaint with gRPC is proto3 making all nested type fields optional while making primitives always present with default values. gRPC is contract based so it makes no sense to me that you can't require a field. This is especially painful from an ergonomics viewpoint. You have to null check every field with a non primitive type.

If I remember correctly the initial version allowed required fields but it caused all sorts of problems when trying to migrate protos because a new required fields breaks all consumers almost by definition. So updating protos in isolation becomes tricky. The problem went away with all optional fields so it was decided the headache wasn't worth it.