The pattern is consistent across three decades: complexity was not removed, it was relocated and then wrapped.
| Era | Shape | What it solved | What it left behind |
|---|---|---|---|
| 2-tier | Client talks straight to a database. | Fast to build; nothing in the middle to go wrong. | Business rules scattered across every client. Change one rule, ship every client. |
| 3-tier | Client, application server, database. | Rules gathered into one enforceable place. | A permanently busy middle tier that every change has to pass through. |
| Framework era | Layers of third-party framework at every tier. | Boilerplate removed; teams productive sooner. | A dependency tree nobody owns, upgrade treadmills, abandonment risk. |
| Composable | Simple client, framework-free backbone, behaviour in data. | Removes the layers rather than wrapping them. | Requires discipline: the configuration is now the product, and must be governed like one. |
Each layer exists to make the layer beneath it tolerable. The abstraction is real work, and it is work you did not write and cannot retire.
Make the decisions yourself, express them as data, and keep the code that reads that data small enough to hold in your head.
Platform-native, dependency-free. It renders state, captures intent and reads configuration. It holds no business rules, so it rarely needs to change.
Single-purpose cloud functions over a key-value store, behind signed endpoints. Each one can be read end to end in a sitting.
Permissions, lifecycle, transactions, behaviour, privilege and whatever this product needs besides. Distributed to everything on a short cycle.
The composable proposition is not a better framework.
It is one fewer of them.