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

31–40 of 111 posts

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

#31

Post by honkhonkpants »

manacit wrote: post #21
the_duke wrote: post #4

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

We use it heavily on multiple projects across languages, and for the most part it works very well. We've had some pain about sharing proto definitions across languages and keeping them in sync. It's probably a much smaller problem when you've got a company-wide monorepo like Google, but you'll definitely have to be vigilant about your build processes to make sure you have the latest definitions shared. Some of the la…

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

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

#32

Post by talideon »

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.

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

#33

Post by justinsb »

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?

I think of GRPC as HTTP/JSON with most of the gotchas fixed for me. HTTP2 makes things like concurrent requests easy. Protobuf fixes schema problems (and I think is technically replaceable if you love your JSON). With the GRPC/protobuf definitions you can easily get clients for many languages.

I'm sure it's possible to create the same thing with HTTP/JSON (and swagger?), but I find it to be more work.

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

#34

Post by adzm »

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?

Perf is one reason indeed; however the integration with protobuf and the tools to generate stubs for various languages from that interface are also very helpful. gRPC is what SOAP should have been, IMO.

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

#35

Post by honkhonkpants »

rakoo wrote: post #27
vtalwar wrote: post #7

Earlier quoted context omitted.

caveat: I work in gRPC team. read target blogpost link to get a sense of experience of some of the companies. https://cloudplatform.googleblog.com/2016/08/gRPC-a-true-Int...

So gRPC evolved out of Stubby. An excellent show of force would be to announce that Stubby has been internally replaced by gRPC, so that the "gRPC is internet scale" assertion can be more than just a gimmick. Knowing nothing of the first one and very little of the second I imagine it would be some important task, so I have to ask: do you plan to internally run with the stuff you open-sourced ? What is missing ?

gRPC faces a longer road to feature parity with Stubby. For external adopters this is not an issue, so it makes sense that it would be available to the public in advance of its adoption inside Google.

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

#36

Post by teen »

honkhonkpants wrote: post #31
manacit wrote: post #21

Earlier quoted context omitted.

We use it heavily on multiple projects across languages, and for the most part it works very well. We've had some pain about sharing proto definitions across languages and keeping them in sync. It's probably a much smaller problem when you've got a company-wide monorepo like Google, but you'll definitely have to be vigilant about your build processes to make sure you have the latest definitions shared. Some of the la…

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

He's got the same protos checked into multiple projects under different files. They need to be kept in sync

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

#40

Post by rakoo »

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?

On top of other answers, I see other advantages:

* streaming in any direction (client->server, server->client, both). Not something easily done with a simple HTTP/JSON endpoint, all handled for you

* Arbitrary cancellation from the client or the server

Post reply on HN