6 ms·

Joel Spolsky had an ancient article titled "Three Wrong Ideas From Computer Science" (2000): https://www.joelonsoftware.com/2000/08/22/three-wrong-ideas-from-co

by ekidd 4y ago

Joel Spolsky had an ancient article titled "Three Wrong Ideas From Computer Science" (2000): https://www.joelonsoftware.com/2000/08/22/three-wrong-ideas-from-computer-science/ https://www.joelonsoftware.com/2000/08/22/three-wrong-ideas-... Some parts of this don't hold up that well. But it has a section titled "Network Transparency" that talks about when transparency of fails. And he calls out three things that make network calls fundamentally different: 1. Availability. It's possible that your network "function" will be impossible to call for some amount of time. 2. Latency. The round-trip latency of RPC calls is extremely high, which affects API design in major ways. Typically, you wind up wanting to perform multiple queries or multiple operations per round-trip. 3. Reliability. Network calls may fail in many more ways than local calls. And these are all issues that have defeated many "transparent" RPC systems in the past. Once your application spreads across multiple machines that interact, then you need to accept you're building a distributed system. And "REST versus RPC" is relatively unimportant compared to the other issues you'll face.

vlovich123 4y ago
Availability and reliability can be handled similarly by thinking about classes of failure modes. Most RPC frameworks have error codes that are too fine grained (see HTTP and it’s cousin REST). Latency is actually mostly solvable with something like cap’n’proto that pipelines the promises so that you can have a normal looking composable functions without the latency cost. Joel Spolsky advice is usually fine but it’s important to understand his commentary tends to be about what ideas are in vogue / dominant at the time of the post and tend to have a more limited perspective (vs listening to researchers in the field actively investigating the problems and investing in ways to find solutions). For example, we have an explicit class that manages RPC calls so that at the call site it looks like a regular function. But since it’s I/O it returns an async so it makes it clear that it’s I/O (which you have to do with non NodeJS JavaScript). Additionally, it returns a promise of a Result object type just like any other failable call which you have to handle properly. Works pretty well (although in retrospect I’m now wishing we had used structured clone instead of JSON to send messages around).
- michaelsbradley 4y ago
  > Most RPC frameworks have error codes that are too fine grained (see HTTP and it’s cousin REST). Are HTTP and its cousin REST examples of RPC frameworks? I don’t think so, and I may have misunderstood your point. But if you do consider them to be RPC, can you explain your reasoning? Despite drawbacks here and there, I do have appreciation for RPC, e.g. JSON-RPC is widely used in the distributed/decentralized tech space I work in. It’s fairly well-specified and well-suited for a variety of use cases: https://www.jsonrpc.org/specification https://www.jsonrpc.org/specification
  - Yoric 4y ago
    Not the GP, but I would definitely consider REST a layer in a RPC framework.
    - indymike 4y ago
      > I would definitely consider REST a layer in a RPC framework. A beef patty is not a hamburger without the bun, pickles and condiments.
  - vlovich123 4y ago
    The distinction that it has to look like a normal function call is unhelpful. To me RPC and IPC are synonymous (which I get isn’t the Wikipedia definition). I lump them all together as “distributed communication”. The actual problems I think about are: * semantics of what the request / response looks like and how failures communicate * how are the APIs composed? Not the local function call, but the functionality calling the API implies (see cap’n’proto’s page on composable remote APIs - it’s really brilliant). * can you communicate across programming languages? * how is ownership of remote resources managed? * how is routing / dispatch of API calls managed? For example “fetch” in JS land looks a hell of a lot to me like a normal function call to me. And I certainly then wrapped it with easier to read APIs that looked more normal and handled routing and error handling for me. The main difference with HTTP is that RPC systems traditionally autogenerate a bunch of code for you. But in HTTP land you now have efforts like OpenAPI to do similar things. So HTTP isn’t RPC but the autogenerated code from a description of the API makes it RPC? That gets you into the ship of Theseus paradox which isn’t helpful. At what amount of wrapping it with local functional calls does distributed API calls transform into RPC? To me it turns out that async / sync is a key distinction and the original sin of RPC in the 80s. It’s also why I view the coloring problem as a good thing (at least given where the tech stack is today). Making functions that may be doing I/O stand out and needing thought is a good thing. The problem with many RPC/IPC mechanisms from the 80s is they tried to make the code seem synchronous not that it looks like a function call. But I haven’t seen any RPC systems where async vs sync is the distinguishing characteristic (eg cap’n’proto and fetch are both async). To me, HTTP, REST, SOAP, COM, gRPC, cap’n’proto, JSON-RPC, XPC, Mach etc all try to solve the same problem of distributed communication and processing, just by making different trade offs. HTTP tried to standardize RPC semantics but you can clearly see it’s optimized particularly around static document retrieval and typical browser tasks. I’ll buy that static document retrieval need not be classified as a remote API but there’s a lot of non static document retrieval that’s layered on the same semantics that is proper API calls (notably REST) tries to get everything to conform to that so that middleware has some convention and you get browser interop. It works surprisingly well because a good majority of apps are CRUD and don’t need anything more. JSON-RPC tries to solve routing/dispatch to be more automated if I recall correctly because REST is such a cluster (look at all the routing libraries which to me are an anti pattern). + JSON-RPC is particularly easy in JS which is usually the language on one side of the transaction. COM solves all of the above and things like distributed ownership of resources, except it historically didn’t have a good security model (I don’t know it well enough to know what’s improved there but I don’t assume it’s stayed static since the 90s even if it hasn’t found traction outside Microsoft). They all try to solve different parts of the problem or have different sets of tradeoffs, but to me it’s fundamentally the same problem. It’s the same reason I don’t view distributed systems as something that requires different machines, CPUs, processes or anything about geography. You can have distributed systems within one process, you can have it within processes on the same CPU, you can have it between CPUs on the same device, etc. Heck, to me even the kernel and user space form a distributed system with syscalls as a primitive RPC mechanism. JNI is a form of RPC too although you’ve seen traditional systems like gRPC supplant it even within process because it moves complexity out of the JNI layer into a simpler system with easier to follow rules. Now you can sometimes makes simplifying assumptions to reduce complexity, reduce power usage etc. and not all distributed systems necessarily have the same sets of problems. But fundamentally to me it’s all the same problem space and why I don’t distinguish the terminology so much.
eikenberry 4y ago
And you can just figure out a solution for these things as there is no one solution. There are many different tradeoffs needed based on the call.
teddyh 4y ago
> he calls out three things that make network calls fundamentally different: Joel Spolsky was not the originator of these ideas; their most famous form comes from about 1994, as written by L Peter Deutsch: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
xg15 4y ago
To JS developers' credit, writing modern JS in many ways already is like writing a distributed system. Even if you stay fully client-side, you have bits of code that are running in different parts of the browser and you have to marshal data back and forth between them. Many web API functions are really RPC calls into a different browser process. JS has has primitives like channels, promises or async/await to deal with those. At least there might be some ways how you could use those as as building blocks for an RPC system which lets you handle the three problems better.
- CipherThrowaway 4y ago
  The client-server relationship is distributed but the intra-browser stuff is just async IPC. Writing robust clients against remote APIs requires considerations around retries, failover, idempotency and read/write consistency. It seems to me that distributed patterns in pure client code are thin on the ground and limited to things like CQRS and Sagas.
- pragmatic 4y ago
  It's not like, it is a distributed system. With PWAs web apps can and do work offline or work limited network. There's a whole series of problems this is useful for.
deleted 4y ago
[deleted]
cyco130 4y ago
Web RPC protocols are not trying to replace local function calls though. They're trying to replace remote API calls (REST, GraphQL etc.). And all remote protocols have to solve problems like availability, latency, and reliability. Those problems remain. This is trying to solve a different problem with different trade-offs. The problem it solves is unnecessary protocol noise and the trade-off is tight coupling between frontend and backend code. I think it's obvious that the trade-off makes sense for small projects and MVPs: most changes require touching both ends and typically the team isn't differentiated between backend and frontend anyway. But even with large projects that have to cater to many clients, a tightly-coupled RPC system can solve problems like overfetching and underfetching as a straightforward method for implementing the BFF pattern[1]. [1] https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0 https://medium.com/mobilepeople/backend-for-frontend-pattern...
- brillout 4y ago
  Exactly. Telefunc is about replacing generic endpoints (RESTful/GraphQL APIs) with tailored endpoints (RPC). That's why the trade-off is simpler architecture (generic endpoints are often an unnecessary abstraction) VS decoupling (tailored endpoints require the frontend and backend to be deployed in-sync). In the long term I foresee RPC to be also used for very large teams. I've ideas around this, stay tuned. I can even see companies like Netflix ditching GraphQL for RPC, although this won't happen any time soon. In the meantime, RPC is a natural fit for small/medium sized teams that want to ship today instead of spending weeks setting up GraphQL.
  - pragmatic 4y ago
    Every generation keeps trying rpc and learns its lesson…eventually. On windows it was DCom, then COM+ then remoting the WCF then who knows I lost track. Rest APIs are simple and easily debuggable, magic remote api layers are not. That’s why REST is still prevalent even in websockets had better better performance parameters (and in my testing it did have performance advantages) yet 7 years after my testing hire many sites are running websockets?
brillout 4y ago
Yes, and that's why in Telefunc's world remote functions are called "telefunctions" to differentiate them from normal functions. Telefunc doesn't try to completely abstract away the network: as you say, it's not possible to abstract away network latency and network failure. Telefunc is about creating network endpoints as easily as creating functions.
rwmj 4y ago
Interestingly there was some research around the latency issue, trying to automatically rewrite the client code so that remote calls are batched together. (This was done in Java where rewriting the .class file was tractable): https://www.doc.ic.ac.uk/~phjk/Publications/CommunicationRestructuring-Middleware2003.pdf https://www.doc.ic.ac.uk/~phjk/Publications/CommunicationRes...

by ekidd 4y ago

vlovich123 4y ago

Availability and reliability can be handled similarly by thinking about classes of failure modes. Most RPC frameworks have error codes that are too fine grained (see HTTP and it’s cousin REST). Latency is actually mostly solvable with something like cap’n’proto that pipelines the promises so that you can have a normal looking composable functions without the latency cost. Joel Spolsky advice is usually fine but it’s important to understand his commentary tends to be about what ideas are in vogue / dominant at the time of the post and tend to have a more limited perspective (vs listening to researchers in the field actively investigating the problems and investing in ways to find solutions). For example, we have an explicit class that manages RPC calls so that at the call site it looks like a regular function. But since it’s I/O it returns an async so it makes it clear that it’s I/O (which you have to do with non NodeJS JavaScript). Additionally, it returns a promise of a Result object type just like any other failable call which you have to handle properly. Works pretty well (although in retrospect I’m now wishing we had used structured clone instead of JSON to send messages around).

michaelsbradley 4y ago
> Most RPC frameworks have error codes that are too fine grained (see HTTP and it’s cousin REST). Are HTTP and its cousin REST examples of RPC frameworks? I don’t think so, and I may have misunderstood your point. But if you do consider them to be RPC, can you explain your reasoning? Despite drawbacks here and there, I do have appreciation for RPC, e.g. JSON-RPC is widely used in the distributed/decentralized tech space I work in. It’s fairly well-specified and well-suited for a variety of use cases: https://www.jsonrpc.org/specification https://www.jsonrpc.org/specification
- Yoric 4y ago
  Not the GP, but I would definitely consider REST a layer in a RPC framework.
  - indymike 4y ago
    > I would definitely consider REST a layer in a RPC framework. A beef patty is not a hamburger without the bun, pickles and condiments.
- vlovich123 4y ago
  The distinction that it has to look like a normal function call is unhelpful. To me RPC and IPC are synonymous (which I get isn’t the Wikipedia definition). I lump them all together as “distributed communication”. The actual problems I think about are: * semantics of what the request / response looks like and how failures communicate * how are the APIs composed? Not the local function call, but the functionality calling the API implies (see cap’n’proto’s page on composable remote APIs - it’s really brilliant). * can you communicate across programming languages? * how is ownership of remote resources managed? * how is routing / dispatch of API calls managed? For example “fetch” in JS land looks a hell of a lot to me like a normal function call to me. And I certainly then wrapped it with easier to read APIs that looked more normal and handled routing and error handling for me. The main difference with HTTP is that RPC systems traditionally autogenerate a bunch of code for you. But in HTTP land you now have efforts like OpenAPI to do similar things. So HTTP isn’t RPC but the autogenerated code from a description of the API makes it RPC? That gets you into the ship of Theseus paradox which isn’t helpful. At what amount of wrapping it with local functional calls does distributed API calls transform into RPC? To me it turns out that async / sync is a key distinction and the original sin of RPC in the 80s. It’s also why I view the coloring problem as a good thing (at least given where the tech stack is today). Making functions that may be doing I/O stand out and needing thought is a good thing. The problem with many RPC/IPC mechanisms from the 80s is they tried to make the code seem synchronous not that it looks like a function call. But I haven’t seen any RPC systems where async vs sync is the distinguishing characteristic (eg cap’n’proto and fetch are both async). To me, HTTP, REST, SOAP, COM, gRPC, cap’n’proto, JSON-RPC, XPC, Mach etc all try to solve the same problem of distributed communication and processing, just by making different trade offs. HTTP tried to standardize RPC semantics but you can clearly see it’s optimized particularly around static document retrieval and typical browser tasks. I’ll buy that static document retrieval need not be classified as a remote API but there’s a lot of non static document retrieval that’s layered on the same semantics that is proper API calls (notably REST) tries to get everything to conform to that so that middleware has some convention and you get browser interop. It works surprisingly well because a good majority of apps are CRUD and don’t need anything more. JSON-RPC tries to solve routing/dispatch to be more automated if I recall correctly because REST is such a cluster (look at all the routing libraries which to me are an anti pattern). + JSON-RPC is particularly easy in JS which is usually the language on one side of the transaction. COM solves all of the above and things like distributed ownership of resources, except it historically didn’t have a good security model (I don’t know it well enough to know what’s improved there but I don’t assume it’s stayed static since the 90s even if it hasn’t found traction outside Microsoft). They all try to solve different parts of the problem or have different sets of tradeoffs, but to me it’s fundamentally the same problem. It’s the same reason I don’t view distributed systems as something that requires different machines, CPUs, processes or anything about geography. You can have distributed systems within one process, you can have it within processes on the same CPU, you can have it between CPUs on the same device, etc. Heck, to me even the kernel and user space form a distributed system with syscalls as a primitive RPC mechanism. JNI is a form of RPC too although you’ve seen traditional systems like gRPC supplant it even within process because it moves complexity out of the JNI layer into a simpler system with easier to follow rules. Now you can sometimes makes simplifying assumptions to reduce complexity, reduce power usage etc. and not all distributed systems necessarily have the same sets of problems. But fundamentally to me it’s all the same problem space and why I don’t distinguish the terminology so much.

eikenberry 4y ago

And you can just figure out a solution for these things as there is no one solution. There are many different tradeoffs needed based on the call.

teddyh 4y ago

> he calls out three things that make network calls fundamentally different: Joel Spolsky was not the originator of these ideas; their most famous form comes from about 1994, as written by L Peter Deutsch: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

xg15 4y ago

To JS developers' credit, writing modern JS in many ways already is like writing a distributed system. Even if you stay fully client-side, you have bits of code that are running in different parts of the browser and you have to marshal data back and forth between them. Many web API functions are really RPC calls into a different browser process. JS has has primitives like channels, promises or async/await to deal with those. At least there might be some ways how you could use those as as building blocks for an RPC system which lets you handle the three problems better.

CipherThrowaway 4y ago
The client-server relationship is distributed but the intra-browser stuff is just async IPC. Writing robust clients against remote APIs requires considerations around retries, failover, idempotency and read/write consistency. It seems to me that distributed patterns in pure client code are thin on the ground and limited to things like CQRS and Sagas.
pragmatic 4y ago
It's not like, it is a distributed system. With PWAs web apps can and do work offline or work limited network. There's a whole series of problems this is useful for.

deleted 4y ago

[deleted]

cyco130 4y ago

Web RPC protocols are not trying to replace local function calls though. They're trying to replace remote API calls (REST, GraphQL etc.). And all remote protocols have to solve problems like availability, latency, and reliability. Those problems remain. This is trying to solve a different problem with different trade-offs. The problem it solves is unnecessary protocol noise and the trade-off is tight coupling between frontend and backend code. I think it's obvious that the trade-off makes sense for small projects and MVPs: most changes require touching both ends and typically the team isn't differentiated between backend and frontend anyway. But even with large projects that have to cater to many clients, a tightly-coupled RPC system can solve problems like overfetching and underfetching as a straightforward method for implementing the BFF pattern[1]. [1] https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0 https://medium.com/mobilepeople/backend-for-frontend-pattern...

brillout 4y ago
Exactly. Telefunc is about replacing generic endpoints (RESTful/GraphQL APIs) with tailored endpoints (RPC). That's why the trade-off is simpler architecture (generic endpoints are often an unnecessary abstraction) VS decoupling (tailored endpoints require the frontend and backend to be deployed in-sync). In the long term I foresee RPC to be also used for very large teams. I've ideas around this, stay tuned. I can even see companies like Netflix ditching GraphQL for RPC, although this won't happen any time soon. In the meantime, RPC is a natural fit for small/medium sized teams that want to ship today instead of spending weeks setting up GraphQL.
- pragmatic 4y ago
  Every generation keeps trying rpc and learns its lesson…eventually. On windows it was DCom, then COM+ then remoting the WCF then who knows I lost track. Rest APIs are simple and easily debuggable, magic remote api layers are not. That’s why REST is still prevalent even in websockets had better better performance parameters (and in my testing it did have performance advantages) yet 7 years after my testing hire many sites are running websockets?

brillout 4y ago

Yes, and that's why in Telefunc's world remote functions are called "telefunctions" to differentiate them from normal functions. Telefunc doesn't try to completely abstract away the network: as you say, it's not possible to abstract away network latency and network failure. Telefunc is about creating network endpoints as easily as creating functions.

rwmj 4y ago

Interestingly there was some research around the latency issue, trying to automatically rewrite the client code so that remote calls are batched together. (This was done in Java where rewriting the .class file was tractable): https://www.doc.ic.ac.uk/~phjk/Publications/CommunicationRestructuring-Middleware2003.pdf https://www.doc.ic.ac.uk/~phjk/Publications/CommunicationRes...