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
The 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 client and 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.
Top comments (0)