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 inefficient most libraries are. But that's not really JSON's fault.
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, this is really nice, as proto3 and GRPC have code generators for a slew of different languages.
There are a lot of other niceties that are useful in gRPC that you don't get with JSON (like streaming data).
Also a protobuf may be stored directly in some of the databases google uses internally, then you have lots of tools around them (diffing with map-reduces done on them, etc.).
Yeah, you can certainly use JSON until you start caring about cost / performance then switch over. I don't use gRPC on hobby projects because writing a flask or express server that receives json payloads is much faster.
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.
>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.
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).
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).
Not really. If you need to support multiple platforms and you need something secure (no DER or BER or...) then protobuf is pretty much unbeatable. Well-maintained Libraries in every language and good generated code based on a simple format.
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.
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 inefficient most libraries are. But that's not really JSON's fault.