It is kind of amazing to me, that we've almost come full circle now from the early days of database driven, server rendered pages. Back then, before ORMs, before even many templating solutions, rendering a page was basically two steps:
- Build usually one, but maybe a few, SQL queries for the database. These queries (as part of their WHERE, GROUP BY, etc clauses) would do the roles of aggregation, summation, and even role based security since the WHERE clause could constrain roles based upon the user's cookie.
- Render the page out by walking this SQL result.
It's been interesting to see the UI layer move out of server rendered pages and into the client, and I do think that moving the web from a "rendering HTML document once" to "in a render loop rendering a DOM" is a step forward not just in flexibility but conceptually. But the data access story is still wildly in flux, and the fact that we are now effectively building a query language and query optimizer that in practice will sit on top of SQL and the RDBMS optimizer makes me feel like this abstraction is definitely too thick. I hope the logical outcome of all this will be a comprehensive data system that ties these pieces together (schema, migration, modelling, performance, data binding, etc.)
I've hoped that this would happen for a while but perhaps as with most things in software engineering a change in the surface syntax and notation (GraphQL) re-frames the problem in the heads of the right people that will be both motivated and able to kill off some sacred cows. I think a data system that draws on the lessons of the RDBMS work of the last several decades, the distributed systems work of just the last decade, while also being in touch with the needs of modern applications has yet to come along -- perhaps it has and I haven't seen it yet.
- Build usually one, but maybe a few, SQL queries for the database. These queries (as part of their WHERE, GROUP BY, etc clauses) would do the roles of aggregation, summation, and even role based security since the WHERE clause could constrain roles based upon the user's cookie.
- Render the page out by walking this SQL result.
It's been interesting to see the UI layer move out of server rendered pages and into the client, and I do think that moving the web from a "rendering HTML document once" to "in a render loop rendering a DOM" is a step forward not just in flexibility but conceptually. But the data access story is still wildly in flux, and the fact that we are now effectively building a query language and query optimizer that in practice will sit on top of SQL and the RDBMS optimizer makes me feel like this abstraction is definitely too thick. I hope the logical outcome of all this will be a comprehensive data system that ties these pieces together (schema, migration, modelling, performance, data binding, etc.)
I've hoped that this would happen for a while but perhaps as with most things in software engineering a change in the surface syntax and notation (GraphQL) re-frames the problem in the heads of the right people that will be both motivated and able to kill off some sacred cows. I think a data system that draws on the lessons of the RDBMS work of the last several decades, the distributed systems work of just the last decade, while also being in touch with the needs of modern applications has yet to come along -- perhaps it has and I haven't seen it yet.