81–90 of 230 posts
Earlier quoted context omitted.
The streaming message transfer modes are the main thing that make it difficult.
Streaming seems like it'd work without too much effort. It'd be less efficient for sure, but it's also not a very common use case.
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…
gRPC is meant for backend microservices among other things, and it's still painful for that for the reasons the article describes, all of which could've been fixed or avoided. Internally Google doesn't even use gRPC, they use something similar that has better internal support according to https://news.ycombinator.com/item?id=17690676 I also don't see what'd stop it from being used generally for websites calling the b…
But that says that they do use gRPC internally on projects that are new enough to have been able to adopt it?
Earlier quoted context omitted.
gRPC is meant for backend microservices among other things, and it's still painful for that for the reasons the article describes, all of which could've been fixed or avoided. Internally Google doesn't even use gRPC, they use something similar that has better internal support according to https://news.ycombinator.com/item?id=17690676 I also don't see what'd stop it from being used generally for websites calling the b…
> Internally Google doesn't even use gRPC, they use something similar that has better internal support according to https://news.ycombinator.com/item?id=17690676 But that says that they do use gRPC internally on projects that are new enough to have been able to adopt it?
Earlier quoted context omitted.
gRPC is meant for backend microservices among other things, and it's still painful for that for the reasons the article describes, all of which could've been fixed or avoided. Internally Google doesn't even use gRPC, they use something similar that has better internal support according to https://news.ycombinator.com/item?id=17690676 I also don't see what'd stop it from being used generally for websites calling the b…
> Internally Google doesn't even use gRPC, they use something similar that has better internal support according to https://news.ycombinator.com/item?id=17690676 But that says that they do use gRPC internally on projects that are new enough to have been able to adopt it?
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)
Earlier quoted context omitted.
> Internally Google doesn't even use gRPC, they use something similar that has better internal support according to https://news.ycombinator.com/item?id=17690676 But that says that they do use gRPC internally on projects that are new enough to have been able to adopt it?
In 2018, there was some kind of push towards gRPC internally, but it was since abandoned and reversed among the few who actually switched. They still don't use it internally, only externally in some places.
I remember being surprised at how hard it was to read the source code for grpc Java. There's an incredible amount of indirection at every turn. This made it extremely hard to get answers to questions that were undocumented. It's a shame because I know Google can put out easy to read code (see: the go standard library).
I think it's partly a culture thing. Java developers love indirection, and they're used to an ecosystem that doesn't want to be understood. An ecosystem that wants you to google whatever obtuse error message it decides to spit out, and paste whatever half thought out annotation some blog post spits back, into your code to make it work. I've worked with people who considered anything that wasn't programmed with annota…
Earlier quoted context omitted.
This anecdote highlights scope creep and mismanagement, not a fault of gRPC.
I think the anecdote highlights that there's no incremental way to approach gRPC, it's not a low risk small footprint prototype project that can be introduced slowly and integrated with existing systems and environments. Which, well, it is a bit of a fault of gRPC.
Reads like a skill issue to me.
[1]: https://github.com/grpc-ecosystem/grpc-gateway [2]: https://github.com/connectrpc/vanguard-go
A lot of this kind of criticism rubs me the wrong way, especially complaining about having to use words or maths concepts, or having to learn new things. That's often not really a statement on the inherent virtue of a tool, and more of a statement on the familiarity of the author. I don't want to sound flippant, but if you don't want to learn new things, don't use new tools :D
That's precisely the problem. The author wants to convince people (e.g., his colleagues) to use a new tool, but he has to convince them to learn a bunch of new things including a bunch of new things that aren't even necessary.