Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC-Go Engineering Practices

grpc.io

Post reply on HN
Print view View original

31–40 of 85 posts

Re: gRPC-Go Engineering Practices

#31

Post by trhway »

willvarfar wrote: post #9
rb808 wrote: post #2

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?

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…

>Afraid I'm going to be contrary and old-fashioned and say I prefer JSON.

history is completing full circle. Before JSON (HTTP REST) there was RPC. JSON was a new and shiny thing while the RPC was for the old-fashioned. The JSON took over exactly for all the great advantages over RPC that you listed (and a bunch of others) and despite all the advantages of RPC that people in this thread tout today as the gRPC advantages. I suspect that in 10-15 years some young guys at Google will come up with gJSON, and their arguments for it will look like your comment today.

Re: gRPC-Go Engineering Practices

#32

Post by Thaxll »

zeveb wrote: post #28
dguaraglia wrote: post #27

Earlier quoted context omitted.

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.

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

Server sent is not stream, it's a pseudo bad implementation on top of http 1.1.

Re: gRPC-Go Engineering Practices

#33

Post by oshanz »

willvarfar wrote: post #9
rb808 wrote: post #2

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?

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 environment variables for get all the bugging information you want.

Re: gRPC-Go Engineering Practices

#34

Post by sulam »

willvarfar wrote: post #9
rb808 wrote: post #2

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?

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…

How did you get access to sniff the network? What IP are you going to sniff for? How are getting keys so you can MITM the traffic?

Basically none of the "advantages" you describe exist when you're in an environment like Google's, and that kind of environment is the sort of environment one uses gRPC (or Finagle, or others) in. IOW, if you can use Wireshark successfully, you have an argument for using JSON. Just keep in mind many people are not in such an environment.

Re: gRPC-Go Engineering Practices

#35

Post by baby »

trhway wrote: post #31
willvarfar wrote: post #9

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…

>Afraid I'm going to be contrary and old-fashioned and say I prefer JSON. history is completing full circle. Before JSON (HTTP REST) there was RPC. JSON was a new and shiny thing while the RPC was for the old-fashioned. The JSON took over exactly for all the great advantages over RPC that you listed (and a bunch of others) and despite all the advantages of RPC that people in this thread tout today as the gRPC advanta…

it's a performance point of view. You will never beat a binary format to transfer data over the wire. Sure it's not as debugable, but if you want speed you don't have much choice. HTTP/2 did the same thing and ditched the textual format of HTTP/1.

Re: gRPC-Go Engineering Practices

#36

Post by puzzle »

trhway wrote: post #31
willvarfar wrote: post #9

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…

>Afraid I'm going to be contrary and old-fashioned and say I prefer JSON. history is completing full circle. Before JSON (HTTP REST) there was RPC. JSON was a new and shiny thing while the RPC was for the old-fashioned. The JSON took over exactly for all the great advantages over RPC that you listed (and a bunch of others) and despite all the advantages of RPC that people in this thread tout today as the gRPC advanta…

Uh, no. If anything, they are switching more workloads to Flatbuffers. Google does a lot of fleet-wide profiling and the encoding and decoding of protocol buffers, which were meant to be efficient, is NOT lost in the noise. Groups like the toolchain teams have a good idea of how many orders of magnitudes in cores are spent doing just that every second. Something like JSON would require probably tens or hundreds of millions of dollars in additional machines for no gain (slightly educated, but still wild guess).

Re: gRPC-Go Engineering Practices

#37

Post by puzzle »

baby wrote: post #35
trhway wrote: post #31

Earlier quoted context omitted.

>Afraid I'm going to be contrary and old-fashioned and say I prefer JSON. history is completing full circle. Before JSON (HTTP REST) there was RPC. JSON was a new and shiny thing while the RPC was for the old-fashioned. The JSON took over exactly for all the great advantages over RPC that you listed (and a bunch of others) and despite all the advantages of RPC that people in this thread tout today as the gRPC advanta…

it's a performance point of view. You will never beat a binary format to transfer data over the wire. Sure it's not as debugable, but if you want speed you don't have much choice. HTTP/2 did the same thing and ditched the textual format of HTTP/1.

Even with a binary format, you have a lot of options. gRPC has plans for binary logging, which Stubby has had for a decade or more. Google's Stubby clients and servers also have built-in HTTP handlers that let you do a lot of interactive debugging, like the /debug/requests interface in golang's net/trace package. Unexpectedly, I found that a much better troubleshooting experience than pouring through logs (also because logs don't capture everything).

Re: gRPC-Go Engineering Practices

#38

Post by Xorlev »

dmayle wrote: post #3
rb808 wrote: post #2

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?

Json is a serialization format. gRPC is both a serialization format and a DDL (data definition language). That means that you are storing your schema, which also happens to contain interoperability features. ...and the serialization format is more efficient.

Disclaimer: I work for Google, but not on gRPC.

It's worth mentioning that gRPC is actually format-agnostic. While I can't say it does the best job of this (gRPC+protobuf works best), there's precedent for using any transport in gRPC. gRPC-Java includes examples of JSON serialization and Thrift serialization.

gRPC is just the transport protocol (its self built on HTTP/2). That said, I'd highly recommend protobufs, they're great. Define your schema in an agnostic way such that it can be easily browsed and compiled to multiple languages.

Re: gRPC-Go Engineering Practices

#39

Post by Xorlev »

dragonwriter wrote: post #19
Thaxll wrote: post #17

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.

HTTP/1.x will allow you to stream requests from the client. It'll also let you stream chunked responses from the server. But it won't let you do both simultaneously without going more exotic.

Speaking from my own experience in Java, especially testing my gRPC/HTTP bridge[1], streaming is never overly easy with HTTP clients. You're usually just handed a byte stream to handle yourself. Streaming to the server from the client has been another really interesting exercise to get right.

That's part of what's nice about gRPC (aside from the RPC model and protobuf serialization). If you want unary semantics, done. If you want streaming, it's just a keyword away, and it works across all languages.

[1] https://github.com/Xorlev/grpc-jersey

Re: gRPC-Go Engineering Practices

#40

Post by bruth »

Slightly off-topic, but related.. I have read that a common practice for managing proto files (or any schema definitions really) is to put them in a separate repo/package to share. It seems pretty straightforward in my head and provides several advantages. However I still ask about any trade-offs when doing this in practice?
Post reply on HN