Ask HN: 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? 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. 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. Can you provide examples of 2 services that interact with one another? Do the services call each other, or do clients call a service that then calls another service? Something we do often is need to fetch metadata from a centralized service for some kind of data before sending the original data + the metadata to an ml inference server. The call to the fetch the metadata and the call to the ml model would both be done over grpc. The calls originate from both inside the system and connected systems. The internal stuff is batch batch jobs that handle small tasks. The external callers are often other (internal) systems that want to access the data our system produces and rarely to send in commands to do stuff. This isn't difficult to research on your own. Why not share knowledge is someone is asking earnestly? Because there's literally nothing in it for me to help this guy unlock the stunning achievement of understanding why and in what manner computer systems communicate. This is intern level information, trivial to learn. What was in it for you to post the message that there is nothing in it for you? If you cannot post a message to help because "there is nothing in it for you"... please tell me what you got from posting this? I really wanna know You must be a joy to work with /s 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? 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. Interesting approach to just do json instead of protobuf!