4 ms·

In 1994 Sun engineers that worked on RPC published a "Note on Distributed Computing" [1] where they argue that hiding remote interactions behind interfaces that

In 1994 Sun engineers that worked on RPC published a "Note on Distributed Computing" [1] where they argue that hiding remote interactions behind interfaces that are designed to look exactly like local interfaces is not a good idea. RPC in itself is not bad, but only if the local<->remote interactions are exposed. Web with ajax makes message passing explicit and obvious, so even not experienced developers know which calls are remote (expensive and can fail). If these interactions are hidden behind RPC API the performance and reliability of apps may suffer. The NewWeb seem to be inspired by past successful frameworks for building desktop applications, such as Delphi or Visual Basic. But these were local frameworks, NewWeb, being a local client - remote server, can't emulate these solutions by masking remote interactions, because it will end in the trap described by the Sun engineers. [1] https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...

pjmlp 9y ago
There were tons of Delphi and Visual Basic projects written with DCOM and MTS in mind. Also both had a plethora of components for network programming. Finally many of those applications were a typical three tier architecture not much different than SPAs, but with a much higher developer happiness.
kelnos 9y ago
I think that advice is a little outdated. Not because it's incorrect, but because we've already taken care of that distinction with common patterns. If something returns a future/promise, it's a signal that the operation is at the very least expensive, and likely non-local. That's a pattern used pretty much everywhere now, and I think developers understand what the implications are. Beyond that, 1994 was a time when RPC was rare in apps that people would run on their desktops. Developers needed a big fat notice that a function call could involve network access because it would be an exception to the norm. Now there are few apps that don't do some sort of RPC, and people are pretty used to dealing with the latency and error-prone nature of making network calls. (Not to say people are always good at dealing with this, but they're at least aware that they're doing RPC without much fanfare needed.)

pjmlp 9y ago

There were tons of Delphi and Visual Basic projects written with DCOM and MTS in mind. Also both had a plethora of components for network programming. Finally many of those applications were a typical three tier architecture not much different than SPAs, but with a much higher developer happiness.

kelnos 9y ago

I think that advice is a little outdated. Not because it's incorrect, but because we've already taken care of that distinction with common patterns. If something returns a future/promise, it's a signal that the operation is at the very least expensive, and likely non-local. That's a pattern used pretty much everywhere now, and I think developers understand what the implications are. Beyond that, 1994 was a time when RPC was rare in apps that people would run on their desktops. Developers needed a big fat notice that a function call could involve network access because it would be an exception to the norm. Now there are few apps that don't do some sort of RPC, and people are pretty used to dealing with the latency and error-prone nature of making network calls. (Not to say people are always good at dealing with this, but they're at least aware that they're doing RPC without much fanfare needed.)