|
|
|
|
|
by sergueif
1660 days ago
|
|
the term "RPC" can be unpacked with a lot of bad baggage. "remote" can imply unnecessary coupling of knowing the exact receiver. "procedure" can imply a hard guarantee that some side effect took place by the time you get a response. "non-RPC", as best I can interpret it, means "broadcasting" useful messages / FYIs without much out-of-band coupling and listening for interesting messages. You don't know who's gonna receive the message, what they'll do with it, "when" they'll act on it. RPC is inspired by "procedure call" on a single CPU, which is the complete opposite. in a "procedure call" you know exactly the implementation you're gonna get, when it will be executed, etc. You can find glimpses of this in lots of companies, when there's heavy use of a message bus like Kafka. Protobufs as "messages" instead of mere procedure "call" arguments. What do you think? |
|