I Reviewed 1,000s of Opinions on gRPC | Hacker News Reader

I Reviewed 1,000s of Opinions on gRPC

konfigthis.com

17 pointsdphuang226 comments

> However, it's important to note that browser support wasn't a primary focus in gRPC's design. This oversight necessitates an additional component, grpc-web, for browser accessibility. Furthermore, external services often have specific needs like caching and load balancing, which are not directly catered to by gRPC. Adopting gRPC for external services might require bespoke solutions to support these features.

The article should mention the Connect protocol for web-based Protobuf messaging and is compatible with gRPC, so it can be used for service-to-service and service-to-web communication:

https://connectrpc.com/

> gRPC is immature

Seven years (the time since Google made it open source) is immature? Plus however long Google used it internally? Berners-Lee invented HTTP and the web in 1989. By 1996 we had Yahoo!, Altavista, Netscape, and the NY Times had a website.

Sad, isn't it?

Old technology <> Mature technology

Yes, but the article mentions age first, then asserts vaguely "needs more tooling". What kind of tooling? For what use?

Okay,so just as an example the very common penetration testing took Burp has no built in support for gRPC.

Maturity is a factor of age AND usage.

If not many people use a technology, even if it's old, it doesn't mature.

I quite like gRPC but unfortunately it suffered from typical google's "old version is deprecated, new version is wip" syndrome.

I used to use it a lot but in time it becomes more of an obstacle than a net positive. http and websockets with json(front end), cbor(back end) or pb(back end) is the way to go. it gives you exactly the same features but zero restrictions. it is nice to have pb schema that is transferable into other languages but you can define schema in anything and port it to anything, it just takes time to initially write it instead of using pb as intermediary. the little layers of code it autogenerates is not worth the limitations you might be needing to overcome in the future with a larger project. also there is massive issue with no value provided vs null or empty or zero value. pb tries to solve this by using wrappers but in code that is massive pain to work with all the nesting. that was actually what broke the camel's back for me.

i just want to mention that i do not use rest, at all. i do use http methods and url routes but i never accept any rest rules for design or behavior. i am using something like json rpc but i am not using a single route to handle all communication. i still use the same approach as grpc does - route per method, but i keep the flexibility of naming and http methods. people seem to be very much stuck with rest and its limitations/rules for some weird reason.

Is there any reason grpc isn't more popular for the public API of stuff? I'd rather work with grpc than ad-hoc "REST" API's 9/10.

i imagine gRPC is less plaintext friendly, which might be one of the reasons why it's less popular as public apis tend to be as agnostic and easy to start with as possible.

Tho i think it's just a cultural, rather than a technical blockage. REST just has more mindshare, and web developers (who make up the majority of devs using public apis) are pushing JSON based REST as the default.

I believe it’s the gRPC’s choice to multiplex on http2 channel and the lack of support for this on the browser side.

Edit: source - https://grpc.io/blog/state-of-grpc-web/

It's had head of line blocking, proxy, and load balancing complications in the past, no? It's annoying to pipe it over Http 1 and get it working in browsers or older runtimes. It's still not easy to make it work in Unity, for example. Http/3 solves it but that's not always available even today.

For a public API you want to provide a clean and easy to use example.

It's much easier to do it with REST. In docs you can just have a _curl_ example. And the JSON req/resp are easy to copy-paste anywhere else. You can start experimenting immediately, even in the same browser tab with js console.

With protobuf there is an initial barrier, because before you start you have to download proto definitions or a client library.

All of these are non-issue if you use grpcurl and enable server-side reflection

You have to use an envoy proxy in front of your service to be able to use it for web. More infra to manage, and I don't think you get the same features as native gRPC.

gRPC was designed with http2, so it's not like you can swap out the transport with websockets.

There is the grpc-web project which uses HTTP1, but it sacrifices a lot of features that the http2 version offers that you might as well just use REST instead for public-facing services.

The next time I want to build an API, I will probably make use of https://github.com/twitchtv/twirp. I like working with Protobuf and having strongly-typed and well-defined messages, but gRPC is way, way too much. It's obviously a Google product, built for what Google needs.

Use Protobuf for messages, but just use HTTP for transport.

Can you summarize why "just use HTTP for transport"? It might be useful for someone to be able to tell if the assessment applies to them. "gRPC is way, way too much" and "I like working [...] strongly-typed [...]" can't be meaningfully applied.

I don't take either at face-value, e.g. I prefer statically-typed languages but wouldn't tell everyone not to use dynamic ones. I've even seen more recent recommendations to use protobuf with all fields being optional.

You probably don't have the problems that the grpc transport layer solves for. It adds significant complexity so cost benefit is low.

Repeated vague aspertions, without clarifying anything or providing specifics. Break out some technicals, please.

Last I checked the grpc transport layer was http with a couple extra headers?

It's http2-based, completely different implementation compared to http1.

It's difficult to stress how little I care about using a decade old+ version of http versus a 2 decade old+ version. This only further exacerbates my feeling that there's not actually a significant & real complaint against grpc or it's complexity, if we're arguing one of the most well established rfc's is the issue. That's not a grpc issue at all.

Does grpc have an issue, or is this just general vague pissy anti-modern bellyaching in general? Cause it started insubstantial as heck to start from & if this is the first go to argument, my gods man, zero tolerance for this whiner shit. This is the times. Grpc is not at fault here for using vaguely modern competent protocols. What shit.

I agree. gRPC shouldn't be at fault. From my understanding, it's browsers (Javascript, rather) that are at fault as they don't implement specific http2 features that gRPC requires when it comes to web, which is why an envoy proxy is required (but also comes with limitations). As a result, when it comes to web comm, gRPC isn't given a chance.

https://yuku.takahashi.coffee/blog/2019/01/grpc-proxy-for-gr...

REST is such a poorly understood term.

gRPC services are by design client-server likely built in a stateless way. It uses HTTP and exploit the same tools that REST would use for layering such as proxies, etc.

Not sure which parts make it more complex.

gRPC is still over HTTP right?

Most of the other arguments are weak too. I'm not convinced gRPC is any better understood.

You mean http as in HTTP1 I'm assuming. It's not; it's HTTP2. It's a binary messaging format over HTTP2. If you want to make it work over HTTP1, you need an envoy proxy to translate. There's a project called grpc-web but it seems dead in the water as it doesn't support things like bi-directional comm that gRPC offers.

I find JSON-RPC to be a useful lightweight alternative. gRPC adds a lot of baggage (which is sometimes warranted).

Reply on news.ycombinator.com