Hacker News Reader

Comment by lemmsjid | Hacker News Reader

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.

View on HN

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

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

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.

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

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.

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.

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

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.

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

This still seems like a massive regression in openness to me.

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

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

Reply on news.ycombinator.com