4 ms·

Half-OT: What's the main use-case for gRPC? I had the impression RPC was seen as a mistake. Sure, gRPC also uses a binary protocol, but that doesn't seem lik

• snipewheelcelly 6y ago
  it's use case is companies that want to use SOAP but don't want to say they use SOAP
  • outworlder 6y ago
    How is it related to SOAP in any way?
    • bubersson 6y ago
      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.
      • thinkharderdev 6y ago
        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"
• q3k 6y ago
  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, ...
  • k__ 6y ago
    Thanks for the explanation! Why wouldn't it be enough to use REST with a protobuf media type?
    • q3k 6y ago
      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 https://cloud.google.com/endpoints/docs/grpc/transcoding [2] - https://github.com/grpc/grpc/blob/master/doc/statuscodes.md https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
      • k__ 6y ago
        Good points. Thanks again!
    • dodobirdlord 6y ago
      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.
    • closeparen 6y ago
      gRPC's HTTP2 transport is basically this, out of the box. You don't need to manually manage routes, handlers, headers, status codes, etc.
  • mradmin 6y ago
• wongarsu 6y ago
  > I had the impression RPC was seen as a mistake. Aren't REST and webhooks just RPC protocols too?
  • k__ 6y ago
    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.
    • dragonwriter 6y ago
      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.
      • k__ 6y ago
        Interesting. That's how I learned it, haha. Thanks for the clarification!
    • greenshackle2 6y ago
      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.
• ublaze 6y ago
  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-migration-to-grpc 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).
• jeffbee 6y ago
  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.
• thinkharderdev 6y ago
  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.
• mnd999 6y ago
  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.
• e12e 6y ago
  > 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 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 https://youtu.be/hOE6nVVr14c