91–100 of 111 posts
Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?
At the moment as long as you want to use the endpoint directly from a browser. gRPC uses some HTTP features that are not [yet] available from within browser JS APIs.
Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?
(Tedious disclaimer: my opinion only, not speaking for anybody else. I'm an SRE at Google.) Performance. gRPC is basically the most recent version of stubby, and at the kind of scale we use stubby, it achieves shockingly good rpc performance - call latency is orders of magnitude better than any form of http-rpc. This transforms the way you build applications, because you stop caring about the costs of rpcs, and start…
Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?
Lets turn the question around: When should you prefer HTTP/JSON: At the moment as long as you want to use the endpoint directly from a browser. gRPC uses some HTTP features that are not [yet] available from within browser JS APIs.
Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?
Any plans for rust lang bindings? (would prefer to avoid FFI to c++)
Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?
Performance and versioning are two large benefits. Performance benefit comes from the fact that schema is defined on each side (generally server / server) so you only send the information bytes. With a good RPC system you can also access specific fields of your structure without unpacking (or very fast unpacking, depends on what RPC system you're using). gRPC uses Google's protocol buffers. https://developers.google.…
CBOR -- Concise Binary Object Notation -- http://cbor.io/ -- is all the performance of a binary protocol, with semantics basically identical to JSON.
I appreciate some of the things protobuf does to help you version, but I also do not appreciate the protobuf compiler as a dependency and a hurdle for contributors, or for wire debugging. CBOR has libraries in every major (and most minor) languages and works without a fuss with tiny overhead, both at runtime and in dependency size. It's pretty pleasant to work with.
Earlier quoted context omitted.
caveat: I work in gRPC team. read target blogpost link to get a sense of experience of some of the companies. https://cloudplatform.googleblog.com/2016/08/gRPC-a-true-Int...
So gRPC evolved out of Stubby. An excellent show of force would be to announce that Stubby has been internally replaced by gRPC, so that the "gRPC is internet scale" assertion can be more than just a gimmick. Knowing nothing of the first one and very little of the second I imagine it would be some important task, so I have to ask: do you plan to internally run with the stuff you open-sourced ? What is missing ?
As an ex-Googler, using gRPC feels just like using Stubby: the interfaces are the same, the serialization code is the same, the only thing different is the networking code and transparent hooks into other systems.
Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?
Earlier quoted context omitted.
Lets turn the question around: When should you prefer HTTP/JSON: At the moment as long as you want to use the endpoint directly from a browser. gRPC uses some HTTP features that are not [yet] available from within browser JS APIs.
A gRPC->JSON proxy service is simple. I'd use gRPC inside my datacenter, and convert to JSON on the way in and out of the browser.
e.g.: Will it have things like monitoring (we've handled x calls to this API in the last hour, the average API call took y milliseconds). Clustering? (a client connects to a list of grpc servers, if one server goes down, the client will automatically connect to the next on the list)? And load balancing?
If not, are there existing third party tools to implement these, or is the expectation that the community will create these?