51–60 of 85 posts
Does anyone have experience with both gRPC and Thrift? I'd be curious to know how they compare.
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…
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 mi…
Earlier quoted context omitted.
I fully agree, but want to point out that JSON can be compressed.
You're absolutely right. Auth0 shows that when compressed, protobufs don't provide a great benefit vs JSON. Something I've read from others is that gRPC is not the easiest thing to use directly in SPA. If you have services exposed to a web front end and mobile, double exposing a REST-ish API + gRPC might not be worth it. This is a problem with which I'm currently struggling. https://auth0.com/blog/beating-json-perfor…
It will be huge when that's a reality and we start building all of our APIs around protobuf.
Has anyone found a good resource on using gRPC directly in a JS client? I've looked at using gRPC. My current challenge is that I want to support a website/webgateway on one side and mobile gateway on the other. If I use Swift or Java on the mobile side, it's easy. If I use Ionic Framework, I'm in the same spot as with the web gateway; probably better off with HTTP + RPC.
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.
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…
My use is not at all complex but I can't imagine that more involved streaming would be any tougher.
[1] https://github.com/chrissnell/gopherwx/blob/master/storage_g...
[2] https://github.com/chrissnell/grpc-weather-bar
Edit: here's a simple example protobuf definition for streaming to a client: https://github.com/chrissnell/gopherwx/blob/master/protobuf/...
Is it possible to add a middleware which does gRPC JSON?
Earlier quoted context omitted.
I fully agree, but want to point out that JSON can be compressed.
You're absolutely right. Auth0 shows that when compressed, protobufs don't provide a great benefit vs JSON. Something I've read from others is that gRPC is not the easiest thing to use directly in SPA. If you have services exposed to a web front end and mobile, double exposing a REST-ish API + gRPC might not be worth it. This is a problem with which I'm currently struggling. https://auth0.com/blog/beating-json-perfor…
Has anyone found a good resource on using gRPC directly in a JS client? I've looked at using gRPC. My current challenge is that I want to support a website/webgateway on one side and mobile gateway on the other. If I use Swift or Java on the mobile side, it's easy. If I use Ionic Framework, I'm in the same spot as with the web gateway; probably better off with HTTP + RPC.
Does this work? https://github.com/grpc-ecosystem/grpc-gateway Seems to generate a REST proxy server side.
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?
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…
Chunked encoding allows to do something like what gRPC does, but it's my understanding (I might be wrong) that the data needs to be base64 encoded, whereas HTTP/2 supports raw byte arrays to be sent.