HACKER Q&A
📣 jimmyechan

Have you ever had to set up an RCP/gRPC server? Why?


Why should someone consider setting up an RPC/gRPC server instead of just using REST APIs, GraphQL, and other approaches?

Are there particular types of applications, use cases, or scenarios where the benefits significantly outweigh the added effort of setting up and maintaining an RPC server?

  👤 bediger4000 Accepted Answer ✓
I've done it several times, with different RPC systems.

DCE was the hardest and least flexible. gRPC was the easiest and most flexible. Sun's ONC RPC was easier than DCE, but only a little.

If you have a case where a function call would work locally, gRPC will be better than REST because it forces users to strongly type their arguments rather than stringly type, as REST or XMLRPC allows. There's just less places for semantic arguments to happen. You can pass data structures in a lot of RPC systems, which can make a difference.

👤 lbhdc
I use grpc at work for service to service interaction (there are many many services). The generated code, really gets rid of a lot of effort, and keeps clients and servers in sync. It makes streaming pretty easy too. There are also nice tools in the ecosystem to make custom code generators (maybe you want to generate your db interfaces too) or warn if you are introducing breaking changes to your api contract.
👤 decide1000
I like websockets. Sometimes I hit concurrency or reconnect limitations under load and I move to socketIO which is more high level. I don't like setting up another server just for communication.

I do have Redis running so I was thinking to use that for communication between systems. But I am not sure yet. gRPC seems like an overkill to me. Any thoughts?

👤 austin-cheney
Speed and ease.

Supposedly, according to Google, gRPC is 10-11x faster than HTTP/REST. It’s also dramatically less complicated.

Personally, I found protobuf to be a colossal pain in the ass. For me RPC with JSON proved to be about 7.5x faster (plus or minus 0.5x). Since there is overhead to parsing JSON which is less than the overhead of dealing with protobuf the Google approach proved unnecessarily excessive.

HTTP is unidirectional and forces the insanity of round trips. A primitive full duplex socket independently accepts messages from each direction. Process the messages as they come in. It’s just fire and forget. Stupid simple.

With primitive sockets there is no client/server after connection establishment. Everything is a client. Servers just have a service listener and either side can carry both client and server capabilities. When both sides carry both roles that which comes online last is the client.