←back to thread

Using gRPC for (local) inter-process communication (2021)

(www.mpi-hd.mpg.de)
112 points zardinality | 2 comments | 20 Nov 24 13:42 UTC | HN request time: 0.416s | source
Show context
HumblyTossed ◴[20 Nov 24 16:06 UTC] No.42195231[source]▶
> Using a full-featured RPC framework for IPC seems like overkill when the processes run on the same machine. However, if your project anyway exposes RPCs for public APIs or would benefit from a schema-based serialisation layer it makes sense to use only one tool that combines these—also for IPC.

It might make sense. Usually, if you're using IPC, you need it to be as fast as possible and there are several solutions that are much faster.

replies(3): >>42195492 #>>42195664 #>>42198197 #
1. ks2048 ◴[20 Nov 24 21:15 UTC] No.42198197[source]▶
What are the other solutions that are much faster? (besides rolling your own mini format).
replies(1): >>42214070 #
2. HumblyTossed ◴[22 Nov 24 14:26 UTC] No.42214070[source]▶
> What are the other solutions that are much faster?

Why ask the question, then

> (besides rolling your own mini format)

box it in?

Do you think I'm saying using an RPC is bad? I'm not. I simply took issue with the way the article was worded.

The thing about engineering is you don't want to do what some blogger says is best. You want to analyze YOUR particular needs and design your system from that. So, with every properly engineered solution there are trade-offs. You want easy? It may run slower. You want faster? You may have to roll your own.