21–30 of 85 posts
Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
I found gRPC to be a bit too heavyweight and complex. I'm pretty excited about twirp[1] right now. [1]: https://github.com/twitchtv/twirp
Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
I found gRPC to be a bit too heavyweight and complex. I'm pretty excited about twirp[1] right now. [1]: https://github.com/twitchtv/twirp
Earlier quoted context omitted.
Also streaming that you can't do with regular REST, so think about push notification and the like. One of the biggest advantage imo is the contract between the client and the server, both are always in sync about what to send / receive. I've seen many times things break because x,y,x added a field or change a type that the server / client couldn't understand.
> Also streaming that you can't do with regular REST Nothing about the REST architectural style prohibits a resource (or, rather, a particular resource representation) from being a stream.
Earlier quoted context omitted.
Afraid I'm going to be contrary and old-fashioned and say I prefer JSON. Its never been problematic adding or extending JSON endpoints and its never been a problem using basic gzip compression on the fly either. And JSON endpoints are a damn sight easier to debug and wireshark and all the rest. I've spent a lot of time writing fast JSON serialization for various languages including Java etc; its staggering how ineffi…
There are definitely cases for both. JSON is definitely easier to consume as a human (so for debugging). gRPC was born out of Google's Stubby rpc system[0], which is used heavily for communicating between different jobs. If you are going to stand up a lot of different services that are going to talk, it provides a lot of advantages that you don't get with JSON. For large companies that use multiple program languages,…
But if I were writing the next Uber or Facebook or whatever I'd probably get on gRPC or thrift or another RPC system as soon as we hit a non-trivial number of users.
Does anyone have experience with both gRPC and Thrift? I'd be curious to know how they compare.
I think they're pretty similar and you can't lose either way. Facebook's support of Thrift and Google's of gRPC make both decent options.
One thing I will say about gRPC is that it plays nice with Google's build system (Bazel) and some Google APIs now have first-class gRPC support. If you choose thrift in your stack you'll have to call APIs using JSON or support gRPC anyway if you want to use them for those API calls...so gRPC might be an attractive choice. Furthermore gRPC's go interop is also excellent if you happen to be a fan of golang.
Is this gRPC the same thing as golang net/rpc referred to here: https://news.ycombinator.com/item?id=16170116 ? I don't think so but I've never used either one. >seniorsassycat: I don't understand why AWS released Go support instead of binary support and I don't understand why they chose to rely on go's net/rpc [...] which encodes objects using Go's special [gobs] binary format
Earlier quoted context omitted.
Also streaming that you can't do with regular REST, so think about push notification and the like. One of the biggest advantage imo is the contract between the client and the server, both are always in sync about what to send / receive. I've seen many times things break because x,y,x added a field or change a type that the server / client couldn't understand.
> Also streaming that you can't do with regular REST Nothing about the REST architectural style prohibits a resource (or, rather, a particular resource representation) from being a stream.
Practical discussion: the biggest advantage of using REST is that you had a client readily available in pretty much every language. Most of those clients haven't been updated to deal with the HTTP/2 machinery necessary to drive streams the way gRPC does.
Earlier quoted context omitted.
> Also streaming that you can't do with regular REST Nothing about the REST architectural style prohibits a resource (or, rather, a particular resource representation) from being a stream.
Academic discussion: wouldn't the "stateless" part of REST preclude using a stream that necessarily needs to keep track of state? Practical discussion: the biggest advantage of using REST is that you had a client readily available in pretty much every language. Most of those clients haven't been updated to deal with the HTTP/2 machinery necessary to drive streams the way gRPC does.
HTTP has supported streaming data for years, e.g. Server-Sent Events[0]. The short version is that you GET a URL, and the body keeps on arriving forever. I'm pretty sure that we had this sort of HTTP streaming back in the late 90s …
I'll grant that many JSON-oriented pseudo-REST clients probably don't support it, though.
Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
Versioning your API is one huge benefit and better done using proto/rpc. If you change your Json schema, have fun propagating that change to all clients without fear. Or hope you've built special infra to do that. Also "just more efficient" is a funny way to characterize the performance difference between just data bytes vs data + structure bytes (read: the gap is large). You gain in transmission and you gain during…
Earlier quoted context omitted.
I found gRPC to be a bit too heavyweight and complex. I'm pretty excited about twirp[1] right now. [1]: https://github.com/twitchtv/twirp
What have you find too complex about protobuffs? Unfortunately twirp is go-only.