3 ms·

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.