Database-driven applications

How applications usually get made

A 'traditional' MVC-esque architecture with an API

At each component boundary, there lies the potential for an impedance mismatch: due to some technology or system constraint, some critical piece of the information model doesn't make it across the boundary.

    • The data model may be difficult to express in the constraints of the storage medium (e.g. SQL)
    • The data model is expressed too concretely in the DB (e.g. JSON columns, document stores)
    • The data model may not match the constraints of the communication layer (e.g. REST/HTTP)
    • The API only exposes a limited subset of the information model
    • The front end, as a privileged part of the application, gets to talk to the information model directly and bypass the API's limitations
    • The API exposed to external programs only sees a limited subset of the 'true' API

A simple alternative

Schema as united information model and API

Just let a program run queries against the database. Let me make a TODO on my TODO list by transacting an assertion.

In order for this to be a viable solution, several assumptions must hold:

In short, this solution really only works in the context of local-first software.