4 ms·
The problem with gRPC is the "R". It's been the same with JMI, Corba, ONC-RPC and all the others. Making "procedure calls" remote and hiding them underneath cl
by rswail 2y ago
The problem with gRPC is the "R". It's been the same with JMI, Corba, ONC-RPC and all the others.
Making "procedure calls" remote and hiding them underneath client libraries means that programmers do not consider the inherent problems of a networked environment. Problems like service discovery, authentication, etc are hidden beneath something that "looks like" a local procedure call.
That's one problem, the other is that procedure calls are focusing on the verbs, not the nouns (called "entities" or "resources" in the article).
If you can't express an FSM about a noun and what causes its state to change, then how the hell do you know what it does or how changes to its environment affect it?
If you don't know whether some procedure call is idempotent, how the hell can you write code that handles the various network failure modes that you have to deal with?
- thayne 2y agoThat is a problem, certainly, but not the only one.
- rswail 2y agoMy point is that "procedure calls" have always covered up failure modes and making them "remote" papers over all of the problems of distributed computing. The other problem with "procedure calls" is they are imperative and grow without any constraints on their implementation without very careful design and review. The functionality of the "procedure" is unbound and has unknown dependencies and side effects.
- divan 2y agohttps://scholar.harvard.edu/files/waldo/files/waldo-94.pdf https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf