5 ms·

The problem, I think, is that the article presents all of its views as almost self evidently true. If you distill it down, the complaint is that etcd added gRP

The problem, I think, is that the article presents all of its views as almost self evidently true. If you distill it down, the complaint is that etcd added gRPC. I think it was a good move for an infrastructure piece like etcd to add gRPC. Now I can just grab a generated client in a language of my choice. There's certainly valid critiques of gRPC / protocol buffers but I've found things like gRPC and Thrift to reduce complexity in applications that use them, because there's a thousand interpretations of REST out there, not to mention the crazy things people do with 'simple' HTTP, such as long polling, which introduce implicitly complex semantics into something that is on the surface quite simple.

mikro2nd 6y ago
> the article presents all of its views as almost self evidently true Not so. The article, imho, presents all of its views as unabashedly opinionated views of the author. The complaint that simple, lucid and well-fit functional designs are getting hijacked by large-corp vested interests has been adequately taken up elsewhere in this thread.
chillfox 6y ago
"Now I can just grab a generated client in a language of my choice." Except when you can't because no client is available in your favorite language. Then it is a lot harder than a rest api would have been.
wrsh07 6y ago
I agree with you. I like grpc. But I also think that the original author has a point: for many solo developers it's an extra dependency that they have to learn, and they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.
- lemmsjid 6y ago
  Yep! That's the nuanced argument I'd look for, as opposed to 'gRPC bad, they added it because they're from google!' Simplicity wise my favorite scenario is where if I'm using Python I can pip install an interface (or maven, or NPM, etc. etc) which is the versioned, supported interface for a component. REST + Swagger can help a lot there. So can gRPC. But I can also get how your favorite scenario might be to explore a REST API and build your own client.
- abernard1 6y ago
  > they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound. If you're talking latency, to this day gRPC in dynamic languages is still slower than most fast json implementations in _latency_. It is simply not correct to talk about "performance" this way. If you care about CPU allocation and not burning 70% of your CPU on JSON parsing, then sure. Most companies don't care about that, and I/O is 3 orders of magnitude a bigger problem than in-process parsing for those problems.
  - wrsh07 6y ago
    I think this is another reason why solo developers don't benefit from grpc the way a billion dollar company does: solo developers often aren't using languages that are optimized with grpc (eg they're using python, node, Ruby, sometimes go; they aren't using c++, Java, etc) Obviously these aren't hard and fast rules, but Google can't just spin up 10x more data centers to run their resource intensive stuff in something other than c++ or Java. They need the efficiency in a way solo developers or small teams usually don't.
abernard1 6y ago
> Now I can just grab a generated client in a language of my choice. But you can't curl the state of your infra component without creating a program and downloading the client artifacts. This is a very big step backward from an operability standpoint. > because there's a thousand interpretations of REST out there ...but there weren't a thousand different interpretations of the etcd API out there: there was exactly one. And now there are two, and the one with the most utility (that can be used without generators and in languages where gRPC support is spotty) is being diminished. While I agree with you that there could be design consistency arguments in the abstract for gRPC vs REST as a global architectural pattern, none of those applied to the concrete artifact of etcd client<->server communications.
- lemmsjid 6y ago
  Yeah I don't disagree, I was mainly pointing out that there isn't a black and white 'grpc = bad' argument. Especially since I believe grpc does take steps to mitigate some of the RPC issues you'd have with, say, Thrift. For example having the REST gateway so you can support the curl scenario without any extra work. (For example when building my own Thrift-type services I would do extra work to have a mini REST API for status and other operational curling uses) As to the second part of your argument about there now being a second API, and how that is not necessarily a good thing, I quite agree and can't really speak to the etcd use case, other than that I don't think it's some property of 'Xooglers' to do such a thing to an open source component. I've spent my career using open source components: I've had lone developers who change their APIs willy nilly to fit the pet peeves of their own organization; I've had large companies own an open source component and have it be very disciplined about version migration; I've had lone developers be similarly disciplined; I've had companies make open source projects really complicated.
  - abernard1 6y ago
    > For example having the REST gateway so you can support the curl scenario without any extra work. I would agree with you except for one thing--it's very clear that's a second class citizen. There is this totally extra thing to support the original use case of etcd, and it comes with all the extraordinary quirks of how gRPC protobuf -> JSON serialization works (a strong term in my opinion). It is very very hard for me to not see an unintentional conspiracy to push this very bad standard of gRPC. It does NOT make 99% of real-world programs faster. It does not make operations easier. It is not even a "data" format at all: go try changing an enum in downstream systems. The standard is bad. Objectively, terribly bad. Someone somewhere on HN said that "Google was a ball-pit for gifted children." I kinda laughed at that, but really, after k8s and protobuf3, I won't even grant "gifted". Google is a ball-pit for autistic children who can be funded by their monopoly on search. I'm tired of dealing with their protocols that make everything worse.
duncan_bayne 6y ago
> Now I can just grab a generated client in a language of my choice. No, you can just grab a generated client in a language of your choice if that language happens to be supported by protobuf. This is a massive regression from the openness of HTTP REST APIs.
- lemmsjid 6y ago
  That would have been a critique of Thrift, and a valid one, but gRPC has an http gateway interface with semantics for how the RPC calls map to REST calls and JSON. As long as that is supported, then there does not need to be a regression.
  - duncan_bayne 6y ago
    Sure, if the provider of the gRPC service wishes to also offer an HTTP gateway, that's true. But it's trivially true in the case where the provider does so wish (as it would be true of any protocol with a fully-functional HTTP gateway infront of it), and it's untrue in the case where the provider doesn't. And the provider has to do extra work: "[offering an HTTP gateway] required adding custom options to gRPC definitions in protobufs, and add an additional container running this reverse-proxy server." ( https://wecode.wepay.com/posts/migrating-apis-from-rest-to-grpc-at-wepay https://wecode.wepay.com/posts/migrating-apis-from-rest-to-g... ) This still seems like a massive regression in openness to me.

mikro2nd 6y ago

> the article presents all of its views as almost self evidently true Not so. The article, imho, presents all of its views as unabashedly opinionated views of the author. The complaint that simple, lucid and well-fit functional designs are getting hijacked by large-corp vested interests has been adequately taken up elsewhere in this thread.

chillfox 6y ago

"Now I can just grab a generated client in a language of my choice." Except when you can't because no client is available in your favorite language. Then it is a lot harder than a rest api would have been.

wrsh07 6y ago

I agree with you. I like grpc. But I also think that the original author has a point: for many solo developers it's an extra dependency that they have to learn, and they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.

lemmsjid 6y ago
Yep! That's the nuanced argument I'd look for, as opposed to 'gRPC bad, they added it because they're from google!' Simplicity wise my favorite scenario is where if I'm using Python I can pip install an interface (or maven, or NPM, etc. etc) which is the versioned, supported interface for a component. REST + Swagger can help a lot there. So can gRPC. But I can also get how your favorite scenario might be to explore a REST API and build your own client.
abernard1 6y ago
> they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound. If you're talking latency, to this day gRPC in dynamic languages is still slower than most fast json implementations in _latency_. It is simply not correct to talk about "performance" this way. If you care about CPU allocation and not burning 70% of your CPU on JSON parsing, then sure. Most companies don't care about that, and I/O is 3 orders of magnitude a bigger problem than in-process parsing for those problems.
- wrsh07 6y ago
  I think this is another reason why solo developers don't benefit from grpc the way a billion dollar company does: solo developers often aren't using languages that are optimized with grpc (eg they're using python, node, Ruby, sometimes go; they aren't using c++, Java, etc) Obviously these aren't hard and fast rules, but Google can't just spin up 10x more data centers to run their resource intensive stuff in something other than c++ or Java. They need the efficiency in a way solo developers or small teams usually don't.

abernard1 6y ago

> Now I can just grab a generated client in a language of my choice. But you can't curl the state of your infra component without creating a program and downloading the client artifacts. This is a very big step backward from an operability standpoint. > because there's a thousand interpretations of REST out there ...but there weren't a thousand different interpretations of the etcd API out there: there was exactly one. And now there are two, and the one with the most utility (that can be used without generators and in languages where gRPC support is spotty) is being diminished. While I agree with you that there could be design consistency arguments in the abstract for gRPC vs REST as a global architectural pattern, none of those applied to the concrete artifact of etcd client<->server communications.

lemmsjid 6y ago
Yeah I don't disagree, I was mainly pointing out that there isn't a black and white 'grpc = bad' argument. Especially since I believe grpc does take steps to mitigate some of the RPC issues you'd have with, say, Thrift. For example having the REST gateway so you can support the curl scenario without any extra work. (For example when building my own Thrift-type services I would do extra work to have a mini REST API for status and other operational curling uses) As to the second part of your argument about there now being a second API, and how that is not necessarily a good thing, I quite agree and can't really speak to the etcd use case, other than that I don't think it's some property of 'Xooglers' to do such a thing to an open source component. I've spent my career using open source components: I've had lone developers who change their APIs willy nilly to fit the pet peeves of their own organization; I've had large companies own an open source component and have it be very disciplined about version migration; I've had lone developers be similarly disciplined; I've had companies make open source projects really complicated.
- abernard1 6y ago
  > For example having the REST gateway so you can support the curl scenario without any extra work. I would agree with you except for one thing--it's very clear that's a second class citizen. There is this totally extra thing to support the original use case of etcd, and it comes with all the extraordinary quirks of how gRPC protobuf -> JSON serialization works (a strong term in my opinion). It is very very hard for me to not see an unintentional conspiracy to push this very bad standard of gRPC. It does NOT make 99% of real-world programs faster. It does not make operations easier. It is not even a "data" format at all: go try changing an enum in downstream systems. The standard is bad. Objectively, terribly bad. Someone somewhere on HN said that "Google was a ball-pit for gifted children." I kinda laughed at that, but really, after k8s and protobuf3, I won't even grant "gifted". Google is a ball-pit for autistic children who can be funded by their monopoly on search. I'm tired of dealing with their protocols that make everything worse.

duncan_bayne 6y ago

> Now I can just grab a generated client in a language of my choice. No, you can just grab a generated client in a language of your choice if that language happens to be supported by protobuf. This is a massive regression from the openness of HTTP REST APIs.

lemmsjid 6y ago
That would have been a critique of Thrift, and a valid one, but gRPC has an http gateway interface with semantics for how the RPC calls map to REST calls and JSON. As long as that is supported, then there does not need to be a regression.
- duncan_bayne 6y ago
  Sure, if the provider of the gRPC service wishes to also offer an HTTP gateway, that's true. But it's trivially true in the case where the provider does so wish (as it would be true of any protocol with a fully-functional HTTP gateway infront of it), and it's untrue in the case where the provider doesn't. And the provider has to do extra work: "[offering an HTTP gateway] required adding custom options to gRPC definitions in protobufs, and add an additional container running this reverse-proxy server." ( https://wecode.wepay.com/posts/migrating-apis-from-rest-to-grpc-at-wepay https://wecode.wepay.com/posts/migrating-apis-from-rest-to-g... ) This still seems like a massive regression in openness to me.