Safe client-side SQL sounds like what the author wants. * Consistency when fetching data: define a UI that matches a particular SQL view. * Request batching:

Safe client-side SQL sounds like what the author wants. * Consistency when fetching data: define a UI that matches a particular SQL view. * Request batching: It's probably not hard to send deltas on a large view with server-side support for sessions. * Avoiding network waterfalls: basically the definition of a SQL view, with some session management to de-duplicate traffic when updating the view. A lot of clients support batching queries. * UX when fetching data: this seems entirely like an oversite of some UI packages, but when all the other points line up there are very distinct points in application flow when the UI will know a query and potential update is in progress. * Colocation: the definition of a view is necessarily local. * File size: SQL is pretty lightweight on the schema details in results * Type safety: SQL doesn't support dependent types, but e.g. postgres is pretty type-y * Versioning: no explicit support in SQL but for changes to the UI a new view can be created. For changes to the data model a compatible change to the view can be committed in the same transaction as the data model change. * Realtime updates: the glaring hole in the glory of SQL. You'll have to do some user-defined triggers server-side to support this. * Consistency when updating data: the relational model with constraints enforces this * Optimistic updates: if the theoretical differential view update described above exists then this is pretty trivial. Compare local and remote deltas when refreshing the view and indicate to the user the expected state that wasn't committed. * Request queueing: this one seems to be more of a data model problem. If the data model approximates a state machine and queries are on transitions then yes, they need to be serialized. But why not do complex updates all at once with a multi-statement update transaction that commits or fails atomically? * UX when updating data: presumably a UI tied to a single view is easier to indicate busy-ness for. If an update transaction is in flight, display a spinner. When it fails or commits display an OK or error. * Durability when updating data: this could almost certainly be improved for most sql clients. However, idempotence is definitely covered by conditional update transactions. * Type safety: user defined types if necessary but constraints are where a lot of the type-safety happens in SQL. * Versioning: backward-compatibility by updating mutable views in the same transaction as data model changes. Forward-compatibility by rendering directly from the view that's returned, not expecting any particular view.