5 ms·

> 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 downl

> 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.
  - johnnyAghands 6y ago
    > 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". This made me laugh.
EdwardDiego 6y ago
> But you can't curl the state of your infra component without creating a program and downloading the client artifacts. You can if you enable server reflection[1] and use a tool like grpcurl[2]. [1]: https://github.com/grpc/grpc-java/blob/master/documentation/server-reflection-tutorial.md https://github.com/grpc/grpc-java/blob/master/documentation/... [2]: https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl
- yc12340 6y ago
  > tool like grpcurl Not available in any repositories and largely unknown to general masses (much like gRPC itself). Personally I like gRPC and sometimes use it in projects. But the author is right — attempting to gradually replace an existing HTTP API via gRPC API is like replacing horses with genetically modified cows. You need a very... corrupt mindset to ever attempt anything like that.
  - abernard1 6y ago
    So... being a comment from that "guy" that made the original comment :-) To reemphasize the problem with grpcurl.... it's _still_ static. You must download the artifact. It's like needing a different phone for every person you call (protobuf artifacts) instead of calling different people on the same phone (same artifact, different address and data in payload).
  - EdwardDiego 6y ago
    shrug Was just pointing out that you don't need the .proto files on hand to interact with a gRPC service if you use the above approach.
lima 6y ago
> 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. You can still do this because the gRPC API is also exposed via REST.
GoblinSlayer 6y ago
gRPC also adds its own bugs, which are platform dependent and binding dependent. (I use it)
oh-4-fucks-sake 6y ago
To your point: it's situations like this that could (likely) be mitigated if they would have just upheld backwards compatibility: keep HTTP, add gRPC as alternative, 1st class ways of interacting with the tool. I haven't used etcd directly beyond K8, so I don't know if the new versions inherently invalidated the use of HTTP. But seems to me this is just another example of breaking changes...well...breaking stuff.

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.
- johnnyAghands 6y ago
  > 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". This made me laugh.

EdwardDiego 6y ago

> But you can't curl the state of your infra component without creating a program and downloading the client artifacts. You can if you enable server reflection[1] and use a tool like grpcurl[2]. [1]: https://github.com/grpc/grpc-java/blob/master/documentation/server-reflection-tutorial.md https://github.com/grpc/grpc-java/blob/master/documentation/... [2]: https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl

yc12340 6y ago
> tool like grpcurl Not available in any repositories and largely unknown to general masses (much like gRPC itself). Personally I like gRPC and sometimes use it in projects. But the author is right — attempting to gradually replace an existing HTTP API via gRPC API is like replacing horses with genetically modified cows. You need a very... corrupt mindset to ever attempt anything like that.
- abernard1 6y ago
  So... being a comment from that "guy" that made the original comment :-) To reemphasize the problem with grpcurl.... it's _still_ static. You must download the artifact. It's like needing a different phone for every person you call (protobuf artifacts) instead of calling different people on the same phone (same artifact, different address and data in payload).
- EdwardDiego 6y ago
  shrug Was just pointing out that you don't need the .proto files on hand to interact with a gRPC service if you use the above approach.

lima 6y ago

> 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. You can still do this because the gRPC API is also exposed via REST.

GoblinSlayer 6y ago

gRPC also adds its own bugs, which are platform dependent and binding dependent. (I use it)

oh-4-fucks-sake 6y ago

To your point: it's situations like this that could (likely) be mitigated if they would have just upheld backwards compatibility: keep HTTP, add gRPC as alternative, 1st class ways of interacting with the tool. I haven't used etcd directly beyond K8, so I don't know if the new versions inherently invalidated the use of HTTP. But seems to me this is just another example of breaking changes...well...breaking stuff.