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

41–50 of 111 posts

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

#41

Post by niftich »

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?

> Is it just a perf thing?

Mostly. I can't speak to protobuf's serialization format personally, but similar binary serialization like Thrift's TCompactProtocol or TDenseProtocol outperform JSON and you get schemas for "free*" (as in, in your producer and consumer's glue code by virtue of codegen, and not as an afterthought).

The IDL and codegen is a big part of gRPC and Thrift. The rest is opinionatedness and less cognitive effort -- the format is non-human-readable anyway so less propensity for bikeshedding about cosmetic stuff in JSON.

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

#42

Post by teacup50 »

gorset wrote: post #26
the_duke wrote: post #4

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

We're using grpc-java in production for some of our based backend system, slowly replacing our old netty/jackson based system using JSON over HTTP/1.1. The performance is good, and it's nice to have proto files with messages and services, which acts both as documentation and a way to generate client and server code. Protobuf is much faster, produces less garbage and is easier to work with than JSON/jackson. The gener…

> 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 streams must use odd identifiers.

Identifiers are not reclaimed once a stream is closed. Once you've initiated (2^31)/2 streams, you've exhausted the identifier pool and there's nothing you can do other than close the connection.

For comparison, SSH channels use a 32-bit arbitrary channel identifier, specified by the initiating party, creating an identifier tuple of (peer, channel). Channel identifiers can be re-used after an existing channel with that identifier is closed.

As a result, SSH doesn't have this problem, or the need to divide the identifier space into even/odd (server/client) channel space.

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

#45

Post by wslh »

kpayson64 wrote: post #16
wslh wrote: post #6

The last time I tried gRPC with Python in Windows it didn't compile out of the box.

With the 1.0.0 release, there are Windows binaries for all supported Python versions (2.7, 3.4, 3.5). Make sure you upgrade to the latest version of Pip before trying to pip install grpcio. (The binaries use some ABI tags that are only recognized by newer versions of pip)

Thanks! it works now.

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

#46

Post by Dobbs »

the_duke wrote: 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've seen multiple issues where the library you generate against ends up being incompatible with the library you link against at build time. They finally added a version check as part of the build/run step to prevent this from causing silent runtime errors.

Maybe in a year gRPC will actually be stable, maybe it has been over the last three months. I don't really know but I gave up, am moving my applications off of it and actively pushing for coworkers to do the same.

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

#47

Post by honkhonkpants »

teen wrote: post #36
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).

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

That seems like a "doctor it hurts when ... " scenario, and I don't see why it's specific to protobuf. Any IDL managed that way would have the same problem.

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

#48

Post by jcrites »

teen wrote: post #36
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).

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

That problem can be avoided without monorepos. You primarily need a way to declare a dependency from one package on another at build time, such that the appropriate release gets pulled in. For example, maybe you've depended on version 2 of the interface definition; and in that case the build system fetches the artifacts for interface 2 at build time when building the client. Maven for Java works this way.

Ideally this system would also allow the package owner to release updates within an existing version if they wish. For example, backward-compatible changes to the service interface can be released while keeping the major version 2. In this way, clients automatically consume safe updates, while incompatible or risky changes can be given a major version bump (e.g. to 3). Consumers who want to pin the interface to a specific version like 2.5.1 could do so, in some build systems, though dependencies this specific are rarely useful or a good idea. In my experience it's best for the contract between producer and consumer to be explicitly versioned at the "major version" level, and only implicitly versioned (meaning updates are automatic) at the minor version level.

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

#49

Post by iamgopal »

teacup50 wrote: post #42
gorset wrote: post #26

Earlier quoted context omitted.

We're using grpc-java in production for some of our based backend system, slowly replacing our old netty/jackson based system using JSON over HTTP/1.1. The performance is good, and it's nice to have proto files with messages and services, which acts both as documentation and a way to generate client and server code. Protobuf is much faster, produces less garbage and is easier to work with than JSON/jackson. The gener…

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

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

#50

Post by [deleted] »

teacup50 wrote: post #42
gorset wrote: post #26

Earlier quoted context omitted.

We're using grpc-java in production for some of our based backend system, slowly replacing our old netty/jackson based system using JSON over HTTP/1.1. The performance is good, and it's nice to have proto files with messages and services, which acts both as documentation and a way to generate client and server code. Protobuf is much faster, produces less garbage and is easier to work with than JSON/jackson. The gener…

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

[deleted]
Post reply on HN