gRPC is one of the best decisions we've made at our company. Here's the longer blog post - https://dropbox.tech/infrastructure/courier-dropbox-migratio..., but some things:

1. Performance

2. It's hard to make changes that are backwards incompatible via protobuf (reduces significant source of bugs)

3. Great, standardized observability for every service. Small services don't really need too many custom metrics, since we log a LOT of metrics at the RPC layer

4. Standardization at the RPC layer lets us build useful generic infrastructure - like a load testing framework (where users only need to specify the RPC service, method, and parameters like concurrency, RPS).

It's a generic RPC protocol based on a well-enough-typed serialization format (protobuf) that is battle-tested. You'd use it where you'd use REST/API/JSONRPC/...

Compared to plain JSON/REST RPC, it has all the advantages of protobuf over JSON (ie. strong typing, client/server code generation, API evolution, etc), but also provides some niceties at the transport layer: bidirectional streaming, high quality TCP connection multiplexing, ...

> You'd use it where you'd use REST/API/JSONRPC/

Not really. You'd use it for inter service communication but can't really use it in the browser (see grpc-web)

At my workplace we use gRPC for inter service and client service communication from a VueJS SPA. It took some effort but is working really great right now. A colleague wrote a blog post (actually entire series) about it: https://stackpulse.com/blog/tech-blog/grpc-web-using-grpc-in...

Does gRPC bring fexibility and discoverability like GraphQL?

You can enable reflection API (but must compile your server with it) - e.g. it exposes some well known end-point, which when asked can return you back the other end-points available (services), and then asking each end-point service can return each method - and then for each method - what it takes (assuming as "proto") and returns, also what kind is (one shot, bidi, etc.)

So not the same as GraphQL, as you are not asking about resources/objects, but rather inspecting what can be called and how.

I have not used GraphQL in practice so I can't directly compare them.

What I can say is that in terms of flexibility, protobufs by nature provide us with forward and backward compatibility. We can easily add new fields and eventually deprecate old ones, evolving the API similarly to GraphQL.

Apparently, gRPC also has some introspection capabilities like GraphQL (since again you have a clear protobuf schema) but I have never used them in my clients, and perhaps they are not as baked into the system as in GraphQL.

Thanks for the explanation!

Why wouldn't it be enough to use REST with a protobuf media type?

There is some support for that [1]. I prefer to use native binary gRPC because:

1) REST verb/code mapping is too arbitrary for my taste, I prefer explicit verbs in RPC method names and error codes explicitly designed for RPC [2] and ones that will not be accidentally thrown by your HTTP proxy thereby confusing your client

2) REST stream multiplexing over a minimum amount of TCP connections is difficult to do, I trust the gRPC authors to have done their homework better than the average HTTP library. In addition, you can multiplex multiple gRPC bidirectional streams over a single TCP connection, which is something you can't do over plain HTTP without resorting to websockets.

[1] - https://cloud.google.com/endpoints/docs/grpc/transcoding

[2] - https://github.com/grpc/grpc/blob/master/doc/statuscodes.md

Good points.

Thanks again!

REST is a poor model for many scenarios, most obviously when the client and server aren’t dealing with resources or aren’t trying to maintain a shared model of state. A distributed database consensus protocol is a good example of the former, and an application server streaming metrics to a metric aggregation server is a good example of the latter.

gRPC's HTTP2 transport is basically this, out of the box. You don't need to manually manage routes, handlers, headers, status codes, etc.

> I had the impression RPC was seen as a mistake.

For hypermedia/hypertext Fielding made a solid argument for preferring REST over RPC (mostly because of caching). I still recommend reading his very approachable thesis - these days not so much for the web/REST architecture, but for the other ones, which include modern SPAs (they're not great as hypermedia apps, but fine as networked applications):

https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Apart from caching (and cache invalidation) it's accepted that making the network invisible is a bad idea - it will lead to issues. So remote procedure calls aren't inherently bad, but blurring the distinction too much between local procedure calls and remote ones aren't a great idea. From hung nfs mounts to unpredictable application performance, it is unpleasant.

This Netflix talk on their not-graphql framework gives a very nice summary of when and how you might prefer RPC to REST:

https://youtu.be/hOE6nVVr14c

In many ways comparing REST and gRPC is apples-to-oranges. You can design a gRPC to work according to REST principles, and it is actually generally encourages to do so

And more to the point, the vast majority of "REST APIs" I've experienced in the wild are just RPC-style APIs that use JSON.

RPC is apparently en vogue again. Everything new is old.

It’s a pretty decent implementation of the pattern though. Efficient binary protocol (unlike SOAP), built in security and none one of the complexity of object request brokers. Although you might actually want that and you’ll likely end up with something complex like Istio.

> I had the impression RPC was seen as a mistake.

Aren't REST and webhooks just RPC protocols too?

> Aren't REST and webhooks just RPC protocols too?

REST is not, but the thing that isn't REST that lots of people call REST is basically just RPC-over-HTTP-with-JSON.

Are they?

I thought the difference is, that RPC hides behind a function that looks like it would behave like it was local, but in fact does a remote call and REST explicitly states that things happen remote.

REST is centered on resources (nouns), RPC is centered on procedures (verbs). REST is more constrained.

A Remote Procedure is just that, a procedure. Procedures don't have many constraints. They can implicitly change the state of resources on the server. They can do whatever you want.

REST APIs are supposed to be designed around state transfer. You transfer the state of a resource from server to client with a GET. You transfer the state back to the server with a POST/PUT. The operations are supposed to be 'stateless' in that the result is not supposed to depend on the pre-existing state of the resource on the server.

To give a silly example, let's say I have a Counter service. In RPC I could expose a incrementByOne procedure. And then clients could just call:

    incrementByOne(id=1)

In REST I would have a Counter resource. The RESTful way to increment the counter would be:

    GET /api/counter/1
    -> OK {'id': 1, 'value': 12}

    PUT /api/counter/1 {'id': 1, 'value': 13}
    -> OK

It's more cumbersome, but notice that unlike the RPC call, the result of the PUT request doesn't depend on the current state in the server. The counter will always end up at 13. The PUT request is idempotent, I can repeat it n times and end up with the same result. Obviously that's not true with the RPC call. Notice also that the client must implement its own logic for incrementing.

You could design a RESTful RPC, where the only methods are like:

    getCounter(id) -> Counter

    createCounter(Counter) -> id

    putCounter(Counter)

The opposite, RPC over REST, doesn't really work. I guess you could try representing procedures as resources but it would be incredibly awkward. That's why I say REST is more constrained.

With well designed REST you should end up with very decoupled logic between server and client since all they can do is transfer state, they each have they wholly separate logic to deal with the state.

With RPC you can end up with some real spaghetti, where the logic of client and server are intertwined. But not everything can be modeled cleanly as resources, sometimes you really do just want to execute some logic on the server.

Not only is that not a difference, neither one of those things is true.

Any remote interface tends to “hide behind” a local function, that's just how structured programming (of which most more advanced paradigms are refinements) works. And Remote Procedure Call is fairly express that things happen remotely.

Interesting. That's how I learned it, haha.

Thanks for the clarification!

gRPC is not necessarily binary. It is often conflated with protobuf but it is in fact payload format agnostic. You can run it with JSON payloads if you want.

it's use case is companies that want to use SOAP but don't want to say they use SOAP

How is it related to SOAP in any way?

I'm not OP, but the main parallel is a well defined schema of communication between the services using different underlying technologies.

SOAP is in my experience really hard to use and get right, compared to protobufs that bring well understandable set of primitives and intuitive support in many languages. gRPC is a solid carrier for protobufs. Yes, gRPC has many cons (e.g. with undefined/nil values, etc.), but overall it has worked great for our usecases.

Yeah, one way I've describe gRPC to colleagues (which may help or hurt depending on the perspective) is that is "SOAP, but without all the lunacy"