Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC: Internet-scale RPC framework is now 1.0

cloudplatform.googleblog.com

Post reply on HN
Print view View original

81–90 of 111 posts

Re: gRPC: Internet-scale RPC framework is now 1.0

#81

Post by vamega »

bagder wrote: post #52
teacup50 wrote: post #42

Earlier quoted context omitted.

> This turned out to be caused by HTTP/2.0 which only allows 1 billion streams over a single connection. Hilarious. People called this issue out as an obvious flaw when HTTP/2.0 was first proposed, got ignored, and here the issue is. For those unfamiliar: HTTP/2.0 uses an unsigned 31-bit integer to identity individual streams over a connection. Server-initiated streams must use even identifiers. Client-initiated stre…

It was not ignored, it was very much made on purpose because of a certain popular programming language not having unsigned 32 bit variables...

Are you talking about Java?

Re: gRPC: Internet-scale RPC framework is now 1.0

#82

Post by GauntletWizard »

manacit wrote: post #73
honkhonkpants wrote: post #31

Earlier quoted context omitted.

Could you expound upon the problem of keeping your protocol definitions in sync? In my experience this is the strength of protocol buffers: if you follow a few rules, your systems can successfully be decoupled. Some of the rules are never re-using a tag number and never changing a type in an incompatible way (e.g. string->bytes might be ok, but int32->bytes is not).

Yeah! I think a few responses have covered this below, but I'll give you our spin (and why it's painful, compared to what people have offered up). Most of the projects that we're integrating gRPC into are existing codebases that have their own build tools that are (mostly) in isolation. JSON schemas have been agreed on beforehand, and there are separate client implementations in different languages that basically exi…

There's no need to pull the proto file on every build. Proto also has a set of rules for how to maintain wire-compatibility across versions[1]. Following those rules and distributing the definition only when you need new fields should be sufficient.

That said; If you've got a set of shared proto definitions, you should probably either go to a monorepo, or share the shared bits with a git submodule. Doesn't prevent you from needing to follow those conventions, but does make it far easier to debug when things changed.

[1] https://developers.google.com/protocol-buffers/docs/proto3#u...

Re: gRPC: Internet-scale RPC framework is now 1.0

#83

Post by bastijn »

Would it be worth it to use protocol buffers just for the serialization. To replace a current traditional variant. So not for small http communication but for larger persistent storage. Does it help for versioning purposes and preparing for the future when your product might go from traditional to web. Performance aside, it's a clear win there. It seems you have some overhead against in-code solutions (separate .proto files) but it may pay off in versioning and future of your product given all movements to Web etc.

Re: gRPC: Internet-scale RPC framework is now 1.0

#86

Post by Matthias247 »

talideon wrote: post #32
tptacek wrote: post #25

Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?

Significantly less overhead and the benefits of Protocol Buffers on top of that. If performance isn't a big deal, JSON-RPC over HTTP or something like it is fine. If it's critical, something like gRPC makes more sense.

If you do json rpc over HTTP/2 the performance will actually not be that different. The serialization layer is different and for sure protobuf will be fast to (de)serialize than JSON, but for most applications serialization is not the bottleneck (you can e.g. bury a lot more performance in the HTTP implementation).

Re: gRPC: Internet-scale RPC framework is now 1.0

#87

Post by raspasov »

euyyn wrote: post #85
raspasov wrote: post #79

Can someone explain how is GRPC significantly better than WebSockets? I have used it for a few weeks and was very underwhelmed by it.

What is your use case, and what issues did you find?

Incomplete or completely lacking documentation for Objective C and Java, weird bugs, random disconnects. Overall it feels like the Ruby on Rails of networking - an opinionated package/framework that tries to do too much. Also, the whole concept of "as easy as a a local functional call" is a flawed, leaky abstraction.

Re: gRPC: Internet-scale RPC framework is now 1.0

#88

Post by asuffield »

tptacek wrote: post #25

Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?

(Tedious disclaimer: my opinion only, not speaking for anybody else. I'm an SRE at Google.)

Performance. gRPC is basically the most recent version of stubby, and at the kind of scale we use stubby, it achieves shockingly good rpc performance - call latency is orders of magnitude better than any form of http-rpc. This transforms the way you build applications, because you stop caring about the costs of rpcs, and start wanting to split your application into pieces separated by rpc boundaries so that you can run lots of copies of each piece.

I cannot sufficiently explain how critical this is to the way we build applications that scale.

Re: gRPC: Internet-scale RPC framework is now 1.0

#89

Post by Matthias247 »

IshKebab wrote: post #60
the_duke wrote: post #4

Anyone here who tried out gRPC or is using it in production, and can share some experiences?

I've used it. It's easy to use and very capable. My favourite feature is that it supports streaming objects, in both directions. In other words you can do an RPC call where the input and/or output is an asynchronous stream of objects. Every RPC system needs this, or you end up with hacks like HTTP long polling. My least favourite feature is that it is tied to HTTP2. I'm not sure what you're supposed to do if you are…

Agree on this point. The most innovative feature is streaming, which enables some very powerful scenarios.

The tying to HTTP/2 and especially the way it is done is also not my cup of tea. E.g. if it wouldn't have chosen to use HTTP trailers (which are mostly unsupported) it could be implemented with a lot more HTTP libraries. It's also sad that it doesn't run in current browsers because of the lack of trailer support as well as streaming responses there. With putting a little bit more thoughts in it (maybe choosing multiple content types/body encodings) this could have been supported - at least for normal request/response communication without streaming.

Regarding microcontrollers: It should be possible to implement HTTP/2 and gRPC also on microcontrollers, but imho it will neither be easy nor necessarily a good choice. Implementing HTTP/2 with multiplexing will need quite a lot of RAM on a constrained device, especially with the default values for flow control windows and header compression. You can lower these through SETTINGS frames, but that might kill interoperability with HTTP/2 libraries that don't expect remotes to lower the settings or to reset connections while settings have not been fully negotiated.

Re: gRPC: Internet-scale RPC framework is now 1.0

#90

Post by Xorlev »

LeonidBugaev wrote: post #39

I'll try to jump on the plane, and announce that latest GoReplay version now supports Thrift and ProtocolBuffers. So if you are looking to load testing (or integration testing) for gRPC based apps check https://goreplay.org

Unfortunate that you didn't mention it was a "pro" feature, of which there seems to be no easy way to obtain it. You need a call to action and an automated process.
Post reply on HN