←back to thread

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

(www.mpi-hd.mpg.de)
83 points zardinality | 2 comments | 20 Nov 24 13:42 UTC | HN request time: 0.419s | source
Show context
pjmlp ◴[20 Nov 24 17:04 UTC] No.42195953[source]▶
> Using a full-featured RPC framework for IPC seems like overkill when the processes run on the same machine.

That is exactly what COM/WinRT, XPC, Android Binder, D-BUS are.

Naturally they have several optimisations for local execution.

replies(3): >>42196335 #>>42197280 #>>42201053 #
jeffbee ◴[20 Nov 24 17:39 UTC] No.42196335[source]▶
Binder seriously underappreciated, IMHO. But I think it makes sense to use gRPC or something like it if there is any possibility that in the future an "IPC" will become an "RPC" to a foreign host. You don't want to be stuck trying to change an IPC into an RPC if it was foreseeable that it would eventually become remote due to scale.
replies(5): >>42196677 #>>42197248 #>>42198111 #>>42198183 #>>42198692 #
1. bunderbunder ◴[20 Nov 24 21:07 UTC] No.42198111[source]▶
This could possibly even be dead simple to accomplish if application-level semantics aren't being communicated by co-opting parts of the communication channel's spec.

I think that this factor might be the ultimate source of my discomfort with standards like REST. Things like using HTTP verbs and status codes, and encoding parameters into the request's URL, mean that there's almost not even an option to choose a communication channel that's lighter-weight than HTTP.

replies(1): >>42201987 #
2. imtringued ◴[21 Nov 24 07:34 UTC] No.42201987[source]▶
Nobody does REST, because nobody needs the whole hateoas shtick. When people say REST, they mean "HTTP API" and I'm not being pendantic here. The difference is very real because REST doesn't really have a reason to exist.