I guess everything old is new again. Welcome JS devs to RPC.
The wisdom I was given by an old hand is that the computer industry goes through a cycle of focus: disk, network, CPU - at any given time the currently 'hot' technology is targeting one of these hot spots.
I am not sure I have lived long enough to see this play out for myself but it seemed that there was some truth to it when I first heard it.
What I just really dislike is all the fanfare and marketing blah. It seems that we can't have a proper conversation about such things. Performance and bottlenecks are always the same. Something is your current bottleneck. You focus on getting rid of that bottleneck and you discover the next bottleneck. There is always one. People will always take advantage of the bottleneck removed and hit the next one. Can't we just openly talk about the fact that we've removed one and the new bottleneck is of a different 'type' (like you say, disk, network, CPU). Do we always have to pretend like something truly new has been found? Can't we acknowledge what we're really doing there?
Different thing, same vein: The recent posts on here about finite automata (aka state machines). These are the bread and butter of computer science. You learn about those in every computer science 101. And in 101.2 you learn about pushdown automata because finite automata can't do everything you might need (i.e. they can't count). Yet the discussion here and the linked articles and frameworks linked to sound like they're completely novel.
History can't repeat because underlying technology always moves forward and that change is so important that it invalidates almost anything to be clasified as total repete.
You are right in that technology changes and different things that were not possible become possible or become mainstream accessible. What I don't like is the complete ignorance of what came before because of marketing. Don't get me wrong, I get it in that sense. It only sells well when you make everyone believe it's the best thing since sliced bread and that you just invented it out of thin air. I don't have to like that though.
We start out with sequential reads being faster for example. Think tape drives and how file formats and search algorithms got optimized for sequential reads being faster. Then hard drives come along where you can suddenly do much faster 'random reads' simply because searching is so much faster in comparison and people take advantage of it. But then you build enough functionality on top of that sudden ability to do random reads relatively fast that it does become the bottleneck and you instead organize things on your HDD such that they result in sequential reads instead. Along come SSDs, which are so much faster overall that you don't have to any longer. Until it repeats and your workloads bottleneck on even an SSDs abilities. But the idea of organizing your files in a certain way or taking advantage of the read characteristics of your storage aren't completely novel at all.
Or take databases. We start out with accessing data by key only, because it's faster. You need to know your access pattern beforehand if you want things to be fast. Someone comes along and invents relational databases and it becomes possible to actually do that in a 'fast enough' way as well because of hardware advances. Suddenly someone else comes along way later and re-invents accessing data by key only if you need 'real speed' (aka NoSQL databases).
Or like in another thread where someone claimed 'the cloud' invented node independent re-attachable networked storage. No they didn't. I'm not sure if that's the earliest but it's the earliest I know of, which are EMC^2 Symmetrix and that was way pre-cloud i.e. in the 1990s. SANs are/were a thing for a long time. Mainstream access to such technologies by simply renting an EC2 instance w/ EBS volumes is something the cloud did give us though.
Just in general I do see in my history this which came through HN a while ago. I never read any of that but it seems a lot like what we did in computer science in uni from a cursory glance: http://infolab.stanford.edu/~ullman/focs.html
Which would you say we're in now?
We’re calling this the cloud, but the first iteration of “the cloud” started with storage enabling efficient, reliable access of data storage being decoupled from individual nodes
I wish every CS curriculum had a mandatory course on the history of CS.
Covering how many times the same ideas have been "new" and then discarded as not useful, only to be rediscovered. It could help reduce the amount of churn in the industry, so we can move forward instead of forgetting and relearning the same things over and over.
You're meant to pretend Bret is giving the presentation in 1973; e.g. his comment about "but there's no way Intel will corner the market and stifle innovation, right?"
For example it's not possible to call JS function, it'll work and they it'll fail to return a result for some reason. Worst thing that could happen is stack overflow but it won't let you call this function.
I think that RPC is fine as long as it's clearly separated and those who read and write code do not mask it behind ordinary innocent looking calls. It's OK to call personApi.getFullName(person.fistName, person.lastName). It's not OK to call person.getFullName().
Like which problems?
Transparency? Nope; the caller still needs to set up where the remote function resides, which of the multiple remote functions with that name must be executed, etc.
Latency? It actually makes it harder - you now need separate plumbing so that calls which take more than $X minutes must be considered failure.
Reliability? Not this one either - the error returned by a function will still have to be handled separately from an error returned by the network.
Primarily, async exposes that the call you are dealing with goes over the network. You can no longer accidentally put a blocking rpc call in the UI thread.
You can easily send multiple concurrent requests without fuzz.
It has built in primitives to add timeouts on any call, even chained ones, without having to rely on complicated thread-watchdogs or checkpointing.
They just provide syntactic sugar papering over them and, what's worse, exactly make you believe that the problems have been solved.
1. It's an abuse of what async/await is. async/await is about concurrency and says NOTHING about the cause of that concurrency.
2. It's an excuse to rationalize what is clearly a bad idea.
RPC should obviously be RPC. What seems obvious to you in that function call isn't going to be obvious in 5-10 years once your sensibilities are gone and it's someone else dealing with the crap you wrote.
We fought so hard to get rid of crazy RPC protocols (COM+, CORBA) and abominations like SOAP and people keep trying to bring them back.
Yes networking is hard. Do everything you can to make it easier to debug. Text protocols, easy to use tools, etc
They have no idea how thankful they should be HTML friendly ("REST") APIs.
Don't wake the RPC eldritch horrors. Let them dream their undead dreams in the stygian depths.
For those that dare re-kindle the old ways of RPC, only despair, anguish and insanity await. The mindless boilerplate, the infinite depths of parser recursion, the envelopes within envelopes, the madness inducing mysteries of undeclared encoding, the deadly omission of byte order markers, the incomprehensibly complex, yet vague error messages... and the network. The network is waiting to devour your function calls, returning only the broken skeleton and ruptured entrails of what were once perfectly beautiful, good, honest and peace loving return values. The old ways must be locked away, and cast into the deepest fissure in the deepest depths of the ocean, where there is no chance they be rediscovered and unwittingly released on humanity.
Or, how I feel when a vendor sends documentation for their SOAP web service.
The only thing worse may be when a vendor sends documentation for their "REST" web service that is clearly just machine reformatted SOAP.
But I keep re-learning what you’re getting at, throughout my career: just keep it simple. Most things can just be simple.
That’s really well put. When I saw this I just thought, well, that’s probably a lot of complexity to save a few lines of code. And then you’ll just add those lines of code back later when you realise that the client stubs are the easy bit.
But for some stack it ain't that easy though. E.g. if you want TypeScript or SSR.