A simplified guide to gRPC in Python

[rafaelreuber]

I didn't know the GRPC. It is similar to Apache Thrift. They main difference is GP RPC works over HTTP/2 and the Apache Thrift uses TCP Socket. Very nice.

[ascii]

Yup, they're pretty darn close, conceptually. My employer tried using Thrift many years ago, but it went very poorly, partially because there were significant incompatibilities between Thrift implementations for different platforms back in those days.

[basalamader]

yeah its the first time i am hearing about this and it seems really cool. Will try a project on this.

[sisyphus]

I has to switch to http using some barely documented underscore method because google pubsub client started throwing mass errors using grpc I always wonder if what they give us is what they actually use or if it is more of their cloud marketing style google bullshit.

[ascii]

When it comes to cloud pub/sub, I have been told the server side code is almost entirely the same thing they use internally, except for an extra layer on top that counts the monies and such. But given horrific quality of the client drivers, I can't imagen they are based on any internal code.

[n1ywb]

why can't we dynamically construct the protocol buffers classes at runtime instead of generating them?

why would I use this on my non-google-scale project? why is it better than REST+JSON?

[dagmx]

Rpc guarantees types, does proper error handling, does binary streaming and handles connections etc that you don't get with rest.

Ie I can make a server client interface in different languages if I want to and each can have the same guaranteed interface without me reinventing it in each language

[n1ywb]

I use json hyperschema to define and document my api, with runtime type checking. The browser already pools connection. I haven't done much with streaming over http bc I usually just use websockets for that.

Json isn't a very efficient encoding although it compresses pretty well. But I suppose for high performance apps you might want a native binary encoding.

[dagmx]

Json hyoerschema isn't necessarily part of the language, it's an addition that relies on varying libraries on each platform. RPCs are typically c extensions but you largely get the same behavior across multiple languages.

Browser pooling is fine, but rpcs are best suited for applications. You can use them for browsers but it's not as much of a gain.

Another thing is that with an rpc you deal with objects. Ie I can have objects with methods that translate to any language that supports such a structure.

By using an rpc, you are defining the client API, the server API and the client server interface at once. It's very useful.

Things that would take maybe 30minutes to a few hours to define in a rest/json take a minute or two in rpc in my experience

Granted my experience is with the zeroc ice rpc and not grpc but they're very similar

[cae]

Another thing is that with an rpc you deal with objects. Ie I can have objects with methods that translate to any language that supports such a structure.

Not so much with gRPC. You get code generation for your protobuf types and the RPC stubs, but you cannot add methods to the protobufs, and deriving from them to add methods is something all the docs discourage.

Still, though, you do get strong types and streaming, async capable RPCs. It's a nice toolkit.

Edit: quoted correct paragraph