Live data from Hacker News

gRPC: Internet-scale RPC framework is now 1.0

cloudplatform.googleblog.com

61–70 of 111 posts

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

#61
post #27

Earlier quoted context omitted.

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.

not to mention the internal infra grows all these knobbly bits as one-off feature requests for large/influential teams, that aren't necessarily useful outside the goog

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

#62
post #46
post #4

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

I'm glad they are releasing version 1.0 but I feel that the maintainers of the Go gRPC team have a lot of work to rebuild trust. I've seen backwards incompatible changes made by core go team members and core gRPC maintainers. Where the API is statically consistent but actually behaves in completely different broken ways. One of these was big enough that I said screw it and am moving that application away from gRPC. I…

You should absolutely hold them to this standard, but only now that they have released 1.0.

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

#64
post #63

Can anyone explain like I'm 5 what an RPC framework is?

You want to call a method in another process, potentially on another machine. In order to do that you both need to agree on what the networking protocol looks like. gRPC uses HTTP/2 for the control and data channel and uses Protocol Buffers to describe the method call, its parameters and ultimately its return values. Since this is standardized across languages it doesn't matter if the caller is Python and the callee is Java, you can still make the method call.

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

#65
post #46
post #4

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

I'm glad they are releasing version 1.0 but I feel that the maintainers of the Go gRPC team have a lot of work to rebuild trust. I've seen backwards incompatible changes made by core go team members and core gRPC maintainers. Where the API is statically consistent but actually behaves in completely different broken ways. One of these was big enough that I said screw it and am moving that application away from gRPC. I…

"Rebuild trust"? This is the first stable release. Every single release before than was called a "Development Release" (and Protobuf 3.0 only came out of beta less than a month ago), so of course they've been breaking things before now.

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

#66
post #27

Earlier quoted context omitted.

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.

It has nonetheless started to replace some uses already.

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

#67
post #52

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

Doubling the number of them doesn't make it more right.

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

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

Apart from the performance gain, the generated stubs (and the generated protobuf classes) are a nice improvement in developer experience.

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

#69

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…

May be I'm stupid, but how hard it is it to reimplement it as 64 bit unsigned ?

It would likely require a new version on the protocol level.

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

#70

So how does service discovery work? Where do I read more?

That's really an orthogonal concern. You could use Consul, DNS, &c. to do that.

It isn't really that orthogonal. Just like authentication, things like service discovery, smart clients (with load balancing, retries, etc) should likely be pluggable with some reasonable defaults, otherwise you will be building your own custom stuff on top of it and lose a lot of the value of having a standard. See Finagle for a more complete RPC framework.
Post reply on HN