Thus they insist on making the nodes (the servers) smart and the clients (leaves) dumb.
The problem with that, of course, is that the clients inevitably gets faster, and cheaper, and software gets pushed to the leaves again.
We're carrying around what used to be super computers.
This is also why I would be very cautious about investing in something that bets on offloading computation from clients: If you time it right, it could be huge for a while, but you're betting against advances in the speed and cost of computation. The same advances you'll rely on to scale and drive down costs.
As such it feels to me like they're playing a game of musical chairs.
1. Software is too heavy, let's push it on the server 2. Dumb client gets faster 3. Servers cost money, let's use the unused CPU cycles on the client 4. Bloatware happens, go back to 1.
No surprise that this means that there is no single solution. Complexity sometimes makes sense at the edges and sometimes make sense in the core. It just depends.
I think we have a lot to learn about building systems that give us the flexibility to move things around as needed. Plan 9 was interesting from that point of view because it gave a way for edge resources and core resources to be composed via 9P at any place in the network.
Consistency is less of a challenge than it might seem. It's a challenge if you're frequently disconnected from the network for extensive periods of time and might access and modify data from multiple disconnected devices in that period (note modify, not augment and create something new, which is easy to accommodate). But supporting that is very different from supporting mostly-local computation.
Years ago, I pushed as much work onto the client as possible to reduce the workload on my servers. Now, people complain if you push too much work onto their phones. They want the server to do the heavy lifting so the app can be more responsive on their low-powered mobile client.
"The internet" doesn't define how much weight each end of a connection should bear. It doesn't really even dictate that there are only two ends.
Should a webapp have a braindead REST api with a select, insert, update, delete for each table of the underlying db model and have the client make 1000 nested calls to the server to render the simplest thing? Or should the server api be much more sophisticated so that a single api call can provide all the information required for the render?
There's no one right answer just because "internet".
I think about a central server with multiple terminals on a network. There the node is the beefy boi and the terminals are just I/O devices. Kind of similar to what MightyApp is doing - except with fewer privacy concerns :)
It is not an axiom though, but rather an architectural guideline that comes with its own set of trade-offs and must be applied judiciously.
But from a business perspective, there is huge value in dumb clients (not for the end-user)