Hacker News Reader

Comment by abernard1 | Hacker News Reader

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

View on HN

> 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/... [2]: https://github.com/fullstorydev/grpcurl

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

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).

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.

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.

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

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

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.

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

gRPC also adds its own bugs, which are platform dependent and binding dependent.

(I use it)

Reply on news.ycombinator.com