Why We’re Switching to gRPC

https://eng.fromatob.com/post/2019/05/why-were-switching-to-grpc/

by protophason • 7 years ago

244 155 7 years ago

eng.fromatob.com

rubenbe• 7 years ago

I recently chose gRPC as a communication protocol between two devices (sort of IoT).

Until now it works perfectly as expected. The C++ code generator provides a clean abstraction plus it saved a lot of time (both in programming and debugging). The gRPC proto file syntax also nudge you in the right direction wrt protocol design.

When trying to "sell" gRPC it helps that there are generators for plenty of languages and it's backed by a major company.

gravypod4• 7 years ago

I wish that tooling around generating protoc into stubs and client libraries was simpler. I wish there was a single command I could run and turn large collection of proto files into libraries for "all" languages (python, java, C++, Node package, etc). Unfortunately there's no universal approach to this.

shereadsthenews11• 7 years ago

bzl build :my_proto_library ?

jsty2• 7 years ago

What makes that impossible now? I'm probably overlooking something in your use case, but couldn't you just have a simple build script / makefile that generated the libraries with a different protoc call for each library?

q3k3• 7 years ago

This seems like an odd requirement. Are you trying to generate stubs for your API users ahead of time? This will likely not work as generated stubs evolve in lockstep with protoc and runtime support libraries, and thus are not guaranteed to work across discrepant versions. Thus, stub code should be generated alongside the consumer/client. It also likely shouldn't be committed into a VCS.

shereadsthenews11• 7 years ago

A couple of subtly wrong points in the article. Firstly gRPC payload can be anything, needs not be an encoded protocol buffer. Secondly there’s not a whole lot of “validation” going on in the protobuf codec. Basically any fundamentally correct buffer encoded as message A will decode successfully as message B for any B. If there are unknown fields they are silently consumed. If there are missing fields they are given the default values and there is no “required” in proto3. So there is significantly less safety, and significantly more flexibility, in gRPC than people generally realize.

duality• 7 years ago

"Basically any fundamentally correct buffer encoded as message A will decode successfully as message B for any B."

This is incorrect. I suspect you're overextending proto3's treatment of unknown fields to include discarding incorrectly typed fields too. If A has field 1 types as an int, and B has field 1 typed as a string, an A message with field 1 set will not parse as a B message. However, if the A message has no fields set, or sets a field number unknown to B, that could parse successfully with "leftover" unknown fields.

shereadsthenews11• 7 years ago

Ok but these messages are isomorphic on the wire:

  message enc {
    int foo = 1;
    SomeMessage bar = 2;
  }

  message dec {
    bool should_explode = 1;
    string why = 2;
  }

You can successfully decode the latter from an encoding of the former.

dweis3• 7 years ago

I don't think this is the case, or at least, I'd expect it to be a bug.

Protocol Buffers should generally be non-destructive of the underlying data. That means even if it encounters the wrong wire type for a field, it should simply retain that value in the unknown field set rather than discard it.

kentonv4• 7 years ago

If A has field 1 types as an int, and B has field 1 typed as a string, an A message with field 1 set will not parse as a B message.

In the C++ reference implementation, which I wrote, this is not true. The field 1 with the wrong wire type would be treated as an unknown field, not an error.

It's possible that implementations in other languages have different behavior, but that would be a bug. The C++ implementation is considered the reference implementation that all others should follow.

However, shereadsthenews' assertion is not quite right either. Specifically, a string field and a sub-message field both use the same wire type; essentially, the message is encoded into a byte string. So if message A has field 1 type string, containing some bytes that aren't a protobuf, and message B has field 1 type sub-message, then you'll get a parse error.

But it is indeed quite common that one message type parses successfully as another unrelated type.

ntenenz• 7 years ago

`required` was removed due to the challenges it introduces in designing backwards-compatible API changes[1].

[1] https://github.com/protocolbuffers/protobuf/issues/2497#issu...

docker_up2• 7 years ago

"Required" fields that are no longer required, and "optional" fields that are no longer optional are basically 6 of one and half a dozen of another.

I'm personally strongly in the "required" camp because at least the interface makes an attempt at giving clues to a user as to what fields are important. If everything is optional, there's no information being passed as to what is important anymore.

stephenr4• 7 years ago

Apart from “well google (created|uses) it” I don’t really get the benefit of gRPC compared to any other rpc, eg jsonrpc or even xmlrpc, both of which are fairly static, open specifications for a way to communicate, rather than actual releases of a library that apparently has a new release every 10 days or so.

wvenable• 7 years ago

Binary. Streaming. Strongly typed (with caveats). There's a whole article about the advantages/differences linked from the top of this page.

stephenr4• 7 years ago

https://news.ycombinator.com/item?id=20023784 Specifically claims that validation isn’t performed as the article mentions

“binary” is not necessarily a benefit, particularly for developer tooling/debugging

Streaming is one area it may have a benefit but honestly the other issues outweigh that possible benefit (and it’s not like there aren’t other ways to stream data to a browser without resorting to polling)

jwalton2• 7 years ago

My API just returned a single JSON array, so the server couldn’t send anything until it had collected all results.

Why can't you stream a JSON array?

Edit: Here's a (hastily created and untested) node.js example, even:

    class JSONArrayStream extends Transform {
        constructor() {
            super({readableObjectMode: false, writableObjectMode: true});
            this.dataWritten = false;        
        }

        _transform(data, encoding, callback) {
            if (!this.dataWritten) {
                this.dataWritten = true;
                this.push('[\n');
                this.push(JSON.stringify(data) + '\n');
            } else {
                this.push(',' + JSON.stringify(data) + '\n');
            }
            callback();
        }

        _flush(callback) {
            this.push('\n]');
        }
    }

cblum• 7 years ago

Of course you're being downvoted. But I'm totally with you on this one.

As someone currently responsible for migrating services to gRPC at my company, I always say that the main reason people are switching is "because Google."

While there are merits to gRPC and protobuf, I don't think there are enough advantages to throw away REST and JSON and all the tooling around it. The moment you start switching, you start feeling the pain.

"Because Google" is also the main reason everyone wants to run their crap on Kubernetes. It's pure hype.

Always makes me think of "You Are Not Google": https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

7812• 7 years ago

Does anybody remember reading an article along the line "we use X because it's cool and trending and we are cool people?" Not saying it's the case here, but did anybody honestly admitted in an article that they used a technology because it makes them look cool?

I do remember reading quite a lot of articles about the inverse of this: "we don't hire people using Windows/IDEs/ because it says a lot about them, a craftsman should chose his tools wisely, ...", but never the positive.

stephenr4• 7 years ago

I got a very strong “kool aid” vibe from this.

I don’t remember any “we don’t hire people on Windows/using an IDE” (the last part would be particularly weird IMO), but I wouldn’t be surprised if somewhere said “if you want to use Windows you’re on your own (support wise) and if it becomes a time sink you switch or find work elsewhere”.

I’ve supported (in terms of dev environment/tooling) people on Macs, Windows and Linux. Windows by far had the weirdest issues to solve/avoid.

7812• 7 years ago

I don’t remember any “we don’t hire people on Windows/using an IDE”

Two famous examples:

http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.htm...

If you are a startup looking to hire really excellent people, take notice of .NET on a resume, and ask why it’s there.

https://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont...

justicezyx3• 7 years ago

The truth is gRPC, like kubernetes, was built with decades of lessons of RPC framework inside a container oriented distributed environment; and more importantly, gRPC is the blessed framework inside Google as well, meaning it's qualified to power the largest and most complex distributed systems in the world (I think it'd safe to omit 'one of' here), which in comparison is not the case for kubernetes.

Addition: Borg and kubernetes are designed with similar goals but different emphasis. They are like complementing twins had different personalities. For this I recommend Min Cai's Kubecon'18 presentation about peleton [1], the slide is titled "comparison of cluster manager architecture".

[1] https://kccna18.sched.com/event/GrTx/peloton-a-unified-sched...

shereadsthenews11• 7 years ago

Wait, I don’t get it. Kubernetes:Borg::gRPC:Stubby. Google uses gRPC internally to the same extent that they use Kubernetes internally, i.e. hardly at all.

mehrdada6• 7 years ago

This analogy is very misleading. Kubernetes is probably never going to run any real workload internally at Google, but gRPC powers all external APIs of Google Cloud, and increasing other Google properties (e.g. ads, assistant), used by mobile apps like Duo and Allo, and have some big internal service use cases. The reason Stubby still dominates internally is simply taking lots of time to migrate to gRPC that might be hard to justify, but I do see gRPC being used very widely internally at Google; it’s simply a matter of time. I don’t see that happening to Kubernetes; it’s a joke when compared to Borg.

Google aside, many other companies like Dropbox rely on gRPC extensively to successfully run infrastructure: https://static.sched.com/hosted_files/grpconf19/f7/Courier%2...

techslave2• 7 years ago

grpc was built way before containers were a thing. jails and zones were barely out of the gate at the time.

justicezyx3• 7 years ago

You are taking about stubby, I would guess.

Borg is cirra 2003, pb/stubby was before that. Gfs probably was similar in timing as stubby. And many other cluster level foundations. In the end, Borg is the true corner stone that ties everything together and completes the Google infrastructure puzzle (or the modern global scale cluster computing).

superfreek• 7 years ago

gRPC is great, but my issues with it are debugging and supporting the browser as a first class citizen.

We've been working hard on OpenRPC [0]. An Interface Description for JSON-RPC akin to swagger. It's a good middle ground between the two.

[0] https://open-rpc.org

denormalfloat4• 7 years ago

Have you looked at gRPC-Web?

huehehue• 7 years ago

I have mixed feelings about gRPC-Web, and welcome alternatives. Setting up a proxy with any sort of non-standard config can be a pain, gRPC-Web doesn't translate outbound request data for you which can get ugly[0], and your service bindings may or may not try to cast strings to JS number types which silently fail if over MAX_SAFE_INTEGER.

[0] Instead of passing in a plain object, you build it as such:

  const userLookup = new UserLookupRequest();
  const idField = new UserID();
  idField.setValue(29);
  userLookup.setId(idField);
  UserService.findUser(userLookup);

The metadata field doesn't seem to mind though...

anderspitman6• 7 years ago

No streaming? I poked through the docs and spec but didn't see it mentioned. Assuming it's just JSON-RPC under the hood that answers my question, but maybe ya'll have added support on top.

qwerty456127• 7 years ago

IMHO the only reason to use HTTP for services today is caching.

ishaanbahal• 7 years ago

Great to see people using GRPC, but this article doesn't state anything that the actual grpc.io website doesn't, except for the OpenAPI comparison.

ec1096853• 7 years ago

Parsing speed shouldn’t be a factor in deciding. Parsing protobufs on the browser is going to be way slower than using a native json parser and even on the server, there are java libraries that are much faster than protobufs, e.g. https://jsoniter.com/

That’s why formats like FlatBuffer where written; however parsing is likely not going to dominate your application, so other factors should influence your decision instead.

kentonv4• 7 years ago

on the server, there are java libraries that are much faster than protobufs

Be careful not to back broad arguments with outlier benchmarks.

In general, it is plainly true that JSON is much more computationally difficult to encode and decode than Protobuf. Sure, if you compare a carefully micro-optimized JSON implementation against a less-optimized Protobuf implementation, it might win in some cases. That doesn't mean that Protobuf and JSON perform equivalently in general.

ec1096853• 7 years ago

What is the reason not to use the micro optimized JSON implementation if parsing becomes your bottleneck?

rurban• 7 years ago

however parsing is likely not going to dominate your application, so other factors should influence your decision instead.

Exactly. If you need performance, you'll use Cap'n Proto or FlatBuffer, which use a native binary interface, so you don't need to create and copy objects, you just map them them in from IO.

anderspitman6• 7 years ago

Sadly, capnproto's awesome RPC system doesn't appear to support streaming, though I do believe gRPC supports FlatBuffers.

pilif• 7 years ago

The article says that one of the advantages of gRPC is streaming and that JSON wouldn’t support streaming.

That’s however just an implementation detail. JSON can easily be written and read as a stream.

Switching your whole architecture, dealing with a binary protocol and the accompanying tooling issues just because of your choice of JSON parser feels like total overkill.

JSON over HTTP is ubiquitous, has amazing tooling and his highly debuggable. Parsers have become so fast that I feel they might even have the opportunity to be faster than a protobuf based solution.

Finally I don’t buy the argument about validation. You have to validate input and output on the boundaries no matter what.

Even when your interface says “this is a double”, it says nothing about ranges (as seen in the article where valid ranges were specified in the comment) for example.

maltalex• 7 years ago

Parsers have become so fast that I feel they might even have the opportunity to be faster than a protobuf based solution.

Not even close. Event new JSON serializers/deserializers aren't magic. Protobuf is a LOT easier to parse, so it's naturally a LOT faster.

First two duck results for "json vs protobuf benchmark":

https://auth0.com/blog/beating-json-performance-with-protobu...

https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers...

ricardobeat• 7 years ago

The first link shows a mere 4% margin when talking to a JavaScript VM.

Even at a 5x improvement, most projects will never reach a point where the transport encoding is a bottleneck. Protobuf has a lot going for it (currently using in a project) but can’t be sold on speed alone.

mehrdada6• 7 years ago

As mentioned in other comments, gRPC transport is orthogonal to Protobuf serialization. The gRPC runtime library takes no dependency on that. You can use gRPC with JSON. It just happens the default code generators use protobuf IDL and serialization. You can use gRPC library with your own JSON based stub generator.

kjeetgill6• 7 years ago

While that's true I think protobufs are (correctly) seen as the standard preferred way to use gRPC. The first point from the main page:

Simple service definition
Define your service using Protocol Buffers, a powerful binary serialization toolset and language

It's a little unfair to call it that orthogonal.

Thaxll3• 7 years ago

You can't do good streaming using REST / JSON, it's either broken / slow / badly implemented. And that's for one direction, bidirectional streaming is not even possible.

EugeneOZ• 7 years ago

Not all of your API endpoints should response with JSON, that's all. Create endpoint for streaming - it's simple solution.

kiliancs• 7 years ago

When you use a microservice-style architecture, one pretty fundamental decision you need to make is: how do your services talk to each other?

Problems I don't have when using Erlang/Elixir umbrella apps + OTP.

techslave2• 7 years ago

answer: for trivial reasons. too bad he didn’t dig deeper.

_ZeD_• 7 years ago

hey, hey! have you known about this new "webservices" stuff? with SOAP you can call remote code as it is here! and with WSDL you can create automatically the client!

nullwasamistake• 7 years ago

Man I miss WSDL. We're building it all over again with gRPC.

docker_up2• 7 years ago

gRPC is exactly like XDR and ONC-RPCs from the Unix days of the 90s, ex. NFS.

adrianmonk• 7 years ago

Short summary of web services:

Phase 1: Ad hoc, free-for-all chaos.

Phase 2: SOAP tries to bring order. It fails mainly because the "S" ("Simple") is a lie.

Phase 3: Pendulum swings hard toward simplicity with HTTP plus JSON plus nothing else, thanks.

Phase 4: Things shift possibly more toward the middle (a little structure), but none of the competing systems have become obvious winners.

crehn• 7 years ago

Most things in life seem to change like a pendulum learning from previous swings, slowly converging to a healthy middle. Extremes are useful since they give perspective and attractive since they're easy to grasp.

Sevii• 7 years ago

Except for the fun time when the WSDL doesn't match the actual implementation because 'they don't support WSDL'. (despite serving one from their SOAP service)

tracker1• 7 years ago

Or worse, when the WSDL has a response type of "Object" ... OMG was this ever painful to generate clients for. Usually cheated and used Node as a bridge service.

time4tea2• 7 years ago

Yeah. Easy things are easy with most technologies... It's only after a while that you start to see the 'problems'.

With grpc... It's designed by Google for Google's use case. How they do things and the design trade-offs they made are quite specific, and may not make sense for you.

There are no generated language interfaces, so you cannot mock the methods. (Except by mocking abstract classes, and nobody sane does that, right)

That's because grpc allows you to implement whatever methods you like of a service interface, and require any fields you like - all are optional, but not really, right.

Things that you might expect to be invalid, are valid. A zero byte array deserialised as a protobuf message is a perfectly valid message. All the strings are "" (not null), the bools false, and the ints 0.

Load balancing is done by maintaining multiple connections to all upstreams.

The messages dont work very well with ALB/ELB.

The tooling for web clients was terrible ( I understand this may have changed )

The grpc generated classes are a load of slowly compiling not very nice code.

Like I say, if your tech and business is like Google's ( it probably isn't) then it's a shoe-in, else it's definitely worth asking if there is a match for your needs.

buckhx• 7 years ago

I am by no means arguing with your general point, but some of these and may be language specific.

For example in Go, the service definitions are generated as interfaces and come with an "Unimplemented" concrete client. We have a codegen package that builds mock concrete implementations of services for use in tests.

Zero values are also the standard in Go and fit most use cases. We have "optional" types defined as messages that wrap primitives such as floats for times when a true null is needed (has been mostly used for update type methods).

The web clients work, but generate ALOT of code. We're using the improbable package so we can provide different transports for broswer vs server JS clients btw.

The big win we've seen from grpc is being able to reason about the entire system end to end and have a central language for conversation and contracts across teams. Sure there are other ways to accomplish that, but grpc has served that purpose for us.

ptoomey36• 7 years ago

Our main hinderance with gRPC was that several disparate teams had strange issues with the fairly opaque runtime. The “batteries included” approach made attempts to debug the root causes quite difficult.

As a result of the above, we have been exploring twirp. You get the benefits of using protobufs for defining the RPC interface, but without quite as much runtime baggage that complicates debugging issues that arise.

denormalfloat4• 7 years ago

There are no generated language interfaces, so you cannot mock the methods.

For Java that isn't true. Java ships with a lightweight InProcess server to stub out the responses to your client.

Load balancing is done by maintaining multiple connections to all upstreams.

Load balancing is fully pluggable. The default balancer only picks the first connection.

The tooling for web clients was terrible

Agreed. This is almost entirely the fault of Chrome and Firefox, for not implementing the HTTP/2 spec properly. (missing trailers).

time4tea2• 7 years ago

There is a big difference in my book between starting up an in process server (requiring all sorts of grpc naming magic) running your extensions to an abstract class inside the grpc magic, and a language level interface.

On the one level you can say new X(new MyService()) or new X(mock(Service.class))) if you have to, and on the other its just loads of jibber-jabber.

kjeetgill6• 7 years ago

With grpc... It's designed by Google for Google's use case. How they do things and the design trade-offs they made are quite specific, and may not make sense for you.

Agreed. It's always important to try to pick technologies that 'align' with your use-cases as well as possible. This is easier said than done and gets easier the more often you fail to do it well! I do think people will read "for Google's use case" and hear "only for Google's scale". I actually think the gRPC Java stack is pretty efficient so it "scales down" pretty well.

I want to skip over some of what you're saying to address this:

Things that you might expect to be invalid, are valid. A zero byte array deserialised as a protobuf message is a perfectly valid message. All the strings are "" (not null), the bools false, and the ints 0.

Using a protobuf schema layer is wayyyy nicer than JSON blobs but I agree that it is misconstrued as type safety and validation. It's fantastic for efficient data marshaling and decent for code generation but it dosn't solve the "semantic correctness" side of things. You should still be writing validation. Its a solid step up from JSON not a panacea.

alasdair_3• 7 years ago

JSON has a bunch of schema systems, including Open API which is a repackaging of Swagger with some extra stuff and is also endorsed by Google.

Do you consider protobuf superior to those alternatives for web-based (rather than server to server) projects?

dub• 7 years ago

You can add whatever custom validation you want on top of proto3 (using annotations if you like). Required fields aren't very useful at a serialization level: adding a new required field would always be a backwards incompatible change. You should never do it. They're only useful if you have total certainty that you can define all your APIs perfectly on the first try. But again, if you really want them you can always build something like https://github.com/envoyproxy/protoc-gen-validate on top. That's the benefit of a simple and extensible system vs one that tries to bake-in unnecessary or problematic default behaviors.

Also: why wouldn't grpc work well with load balancers? It's based on HTTP/2. It's well supported by envoy, which is fast-becoming the de facto standard proxy for service meshes.

alasdair_3• 7 years ago

Also: why wouldn't grpc work well with load balancers? It's based on HTTP/2

You answered your own question.

There is always some bit of older infrastructure, like a caching proxy or “enterprise” load balancer that doesn’t quite understand http/2 yet - it is the same reason so much Internet traffic is still on ipv4 when ipv6 exists - the lowest common denominator end up winning for some subsection of traffic.

dilyevsky4• 7 years ago

The messages dont work very well with ALB/ELB.

Doesn't work on ALB because its HTTP/2 support is trash, not gRPC's fault here. Works fine with NLB btw.

Load balancing is done by maintaining multiple connections to all upstreams.

Again, this is a "feature" of HTTP/2. Use linkerd or envoy that support subsetting among other useful things.

Don't blame your misunderstanding of how technology is meant to be used on said technology.

adamson2• 7 years ago

This feels like a circular argument. Not everyone needs HTTP/2 support (especially for internal services for enterprise applications).

adamson2• 7 years ago

Things that you might expect to be invalid, are valid. A zero byte array deserialised as a protobuf message is a perfectly valid message. All the strings are "" (not null), the bools false, and the ints 0.

How does this work? How do you make, say, all fields but the second null? Do you just send a messages that's (after encoding) as long as the first two fields, where the first field is 0x00 and the second contains whatever data you want?

violinist• 7 years ago

Two things: 1) proto buffers intentionally don't allow null values; values that aren't set will return a default value 2) gRPC uses proto3, which does not distinguish between a field unset and a field set to the default value

damnyou2• 7 years ago

You should never use protobuf types directly in your code. Always convert to native types at the edges — that will let you do validation.

kbwt• 7 years ago

At that point, what does Protobuf really buy you?

mleonhard2• 7 years ago

One more thing that's a show-stopper for any public service: No flow control. This means anybody who can connect to your gRPC server can OOM it.

dikei• 7 years ago

I suppose you can use a proxy to perform rate-limiting.

kjeetgill6• 7 years ago

This article comes at a good time because I've been exploring the OpaenAPI vs. gRPC for a codebase that presently uses neither. Evaluating technology feels like a lot of navel gazing, so it's nice to hear other's experiences even if their uses don't line all the way up with ours.

Disclaimer: Java fanboy bias. For services internal to a company, I think gRPC is an all around win. If you need to talk to browsers integrations, I don't have as many opinions.

Personally, I really prefer working at the RPC layer rather than at the HTTP layer. It's OOP! It's SOA! Pick your favorite acronym! HTTP's use as a server protocol (as opposed to a browser) is mostly incidental. It works great but most of the HTTP spec entirely inapplicable to services. I like named exceptions to 200 vs 5xx 4xx error codes. Do I really care about GET, PATCH, PUT, HEAD, POST for most of my services when all of my KV/NewSQL/API-over-DB services have narrower semantics anyway.

Out of band headers are nice though.

Between protobufs, http2, and a fresh, active server implementation we see pretty solid latency and throughput improvements. It's hard to generalize but I suspect many users will. Performance isn't the only driving factor but it's nice to start from a solid base.

I'm sure missing all the tools like curl and friends is an annoyance, but I like debugging from within my language, and in JVM land at least it's been easy enough.

atombender• 7 years ago

Have you considered GraphQL? Lots of overlap with gRPC, but much more web-friendly. Much better support for optional vs. requires data, too. And comes with server push, replacing the need for WebSockets/SSE.

Only downside I can think of is that there's no analogous mechanism to gRPC streams; you have to implement your own pagination.

kjeetgill6• 7 years ago

I havn't looked into GraphQL much at all, so correct me if I'm mistaken.

From what I understand of it, the big idea is that instead of passing parameters from the client to the server and fully implementing the query logic, stitching, and reformatting etc. on the server side, you now have a way to pass some of that flexibility out to the client. Instead of updating both the server and the client as uses change, more can be done from the client alone.

I spend most of my time on the infra side of things and rarely if ever make my way out to the browser so I can't speak to WebSockets/SSE or web friendliness. Being the "backend-for-backend" I just prefer being more tight-fisted about what my clients can and can't do. I mostly deal with internal customers with tighter SLAs so I like to capacity plan new uses.

Maybe I'm just old fashioned.

ahuang• 7 years ago

gRPC isn't a requirement for response streaming (as is quoted as one of the main reasons for doing the migration). That can all be achieved with http/json using chunked encoding. In fact, that's what the gRPC-gateway (http/json gateway to a gRPC service) does https://github.com/grpc-ecosystem/grpc-gateway.

gRPC adds bi-directional streaming which is not possible in http, but the use cases for that are more specialized.

anderspitman6• 7 years ago

Sure, the actual transfer will be streamed, but most JSON clients wait for the entire response before firing your callback. As far as I know there isn't even a commonly used spec for partially reading a JSON document.

dunk010• 7 years ago

Rich Hickey, the creator of Clojure, gave a talk with some very relevant points in this space (The Language of the System): https://www.youtube.com/watch?v=ROor6_NGIWU

cgdub• 7 years ago

His point about protocol buffers (i.e. schema-out-of-band protocols) is unfortunately brief in this talk.

Depending on your use case, you may have to do a lot to work around protocol buffers not being self-describing. I haven't seen a good description of the problem online, but if you find yourself embedding JSON data in protobufs to avoid patching middleware services constantly, you should look at something like Avro or MessagePack or Amazon Ion.

dustingetz• 7 years ago

"gRPC is great because most systems just glue one side effect to another side effect, so what's the point of packaging that into REST" – I think a HN comment from a googler

The great thing about Clojure is that you can make holistic systems that are end-to-end immutable and value-centric, which means the side effects can go away, which means gRPC stops making sense and we can start building abstractions instead of procedures!

nevi-me3• 7 years ago

I'm yet to see enough services expose a gRPC endpoint, at least other than Google. That'll keep the perception of adoption s/low.

I'm writing this as I take a break from working on a polyglot project made up of Kotlin, Rust, Node, where we use gRPC and gRPC-web. We're slowly stealing endpoints from the other services/languages to Rust.

Without focusing on the war of languages, the codegen benefits of protobufs have made what used to be a lot of JSON serde much easier.

mleonhard2• 7 years ago

Can you point to a single public Google-run gRPC service? I was under the impression that all connections into Google are proxied by GFE (Google Front-End) servers to internal servers running the Stubby RPC server code. GFE is definitely not running gRPC server code. I don't believe a gRPC endpoint could pass Google's own Production Readiness Review process.

terinjokes• 7 years ago

I've seen Google endpoints available over gRPC over the last few years. Many, if not most, of the Cloud endpoints are directly documented as being available over gRPC[0]. For others, like Google Ads, a peak at the client libraries show it's using gRPC[1] as well.

[0] https://cloud.google.com/pubsub/docs/reference/service_apis_...

[1] https://github.com/googleads/google-ads-java/blob/master/goo...

nevi-me3• 7 years ago

The googleapis [1] repo has the publicly accessible gRPC definitions, which you can access directly. I've done this before, though it was a bit tedious as I had to learn how to manually pass Google credentials (documentation wasn't good enough).

[1] https://github.com/googleapis/googleapis

SamReidHughes• 7 years ago

I'd just like to say I appreciate the writing at the beginning of the article.

"While more speed is always welcome, there are two aspects that were more important for us: clear interface specifications and support for streaming."

This offers a quick exit for anybody who already knows about these advantages.

ww520• 7 years ago

Another alternative is Thrift. It got lots of language bindings and the servers superb.

dewey• 7 years ago

There's also https://github.com/uw-labs/bloomrpc/blob/master/README.md which is kinda like Postman but for gRPC. I didn't see it mentioned in the Caveats section of the post so maybe useful to someone else too.

sytelus• 7 years ago

I'd needed RPC framework for few of my projects but every time I'd considered gRPC, I ended up walked away from it. The big issue is that gRPC has a huge amount of dependencies and it tries to a lot of things, many of them might be irrelevant for you but would cause extra headache anyway. When all need is just serializing your stuff and send over the wire, there are much better lightweight frameworks. For C++, I think RpcLib is one of the best. It doesn't even require maintaining .proto file, do "compile" of schems every time you change something, etc. The moral of the story is that always look around instead of just going for the most popular solution first.

j16sdiz• 7 years ago

I don't see the article answering the "why" question. It was just "We don't like what we where using, so we tried gRPC"

signa11• 7 years ago

one fundamental issue with grpc seems to be that every request for a given service ends up either creating a thread or use an existing one from a pool-of-threads. ofcourse, you cannot limit the number of threads because that will lead to deadlocks.

i _suspect_ for google-scale it should all be fine, where available cpu's are essentially limitless, and consistency of data gets handled f.e. due to multiple updates etc. at a different layer.

writing safe, performant, multi-threaded code in presence of signals/exceptions etc. is non-trivial regardless of how your 'frontend' looks like. async-grpc is quite unwieldy imho.

i have heard folks trying grpc out on cpu-horsepower-starved devices f.e. wireless-base-stations etc. and running into aforementioned issues.

Why We’re Switching to gRPC

Related Stories