Web and app development is, fundamentally, a process of working with three major components and two network connections.
Here's a diagram:
client <-internet-> server <-intranet-> store
client is nowadays a reactive application, the
server is often GraphQL or an old-school REST API backed by a web framework or a serverless architecture such as Lambda, and the
store is usually some sort of database, sometimes of the NoSQL variety.
And those two network connections are killer. They're really, really, really, really slow, compared to each component doing internal work.
These days I'm experimenting with my own omakase framework that focuses on realtime data synchronisation between the
server instead of an API, and which moves a lot of app logic from the
server into the
store, which, after all, is the fundamental source of truth, and is already super-optimised to play exactly that role. This vastly simplifies the
server component, as it needs to do not much more than acting as an authentication, routing and rendering layer.
The trick to all this is to implement a unidirectional data flow within the
store as well. All queries are read-only, and mutating data can only occur by adding changelog events, allowing data to be manipulated must as we do with
git, and making it easy to determine the minimal changeset that a particular
client needs to bring it up to date.
All of which is a long-winded way of saying that I think developers should focus more of their attention on the database, as there's still a lot of latent potential there that's waiting to be unlocked.