THE CLIENT
Written in the platform's own language and UI toolkit with no third-party dependencies. It renders state, captures intent, and reads configuration. It holds no business rules of its own, so it rarely needs to change.
Each generation of application architecture solved a real problem and left a larger one behind. The pattern is consistent: 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, and 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. |
A framework is a set of decisions someone else made, delivered as code you now maintain. The composable proposition is to make those decisions yourself, express them as data, and keep the code that reads that data small enough to hold in your head.
The result is a system with three parts and no fourth: a client that renders, a backbone that runs, and key collections that decide. Anything that does not belong to one of those three does not belong in the system.
Written in the platform's own language and UI toolkit with no third-party dependencies. It renders state, captures intent, and reads configuration. It holds no business rules of its own, so it rarely needs to change.
Small single-purpose cloud functions over a key-value store, reached through signed endpoints. No application server, no ORM, no framework runtime. Each function does one thing and can be read end to end in a sitting.
The decisions. Who may do what, what runs when, what gets recorded, how the product behaves and which privileges apply. Held as data, distributed to every client and function on a short cycle.
Tiers, limits, entitlements and feature switches are configuration. They move in minutes, for every installed client at once, with no store review in the path.
Behaviour that would otherwise become branches becomes rows. The code that reads a key collection is written once and stops growing.
There is no dependency tree to keep current, no framework major version to migrate to, and no upstream project whose abandonment becomes your emergency.
Two clients on two platforms read the same key collections and behave identically, because the behaviour was never written into either of them.