4 ms·

UIs are built in terms of trees so it's easier to map a tree of result data into UI components than a flat sql result set. The query is also much more clear an

UIs are built in terms of trees so it's easier to map a tree of result data into UI components than a flat sql result set. The query is also much more clear and concise using a query language closer to pattern matching / query by example rather than a complex SQL join. I've been playing with some code to generate SQL from a simple JSON query by example format and the resulting SQL query is 7x as long and would be next to impossible to write and compose by hand.

simonw 7y ago
This is one of the most convincing arguments I've seen for GraphQL as a language for supporting UIs: that UIs map to trees, and trees aren't nearly as clean in SQL than they are in GraphQL.
- tester756 7y ago
  I don't understand I've been messing with trees in C# with EF Core + MSSQL and it correctly maps schema like Id, Name, ParentId (nullable) into tree, and then into json
jayd16 7y ago
UIs are built in trees? How so more than the RESTful JSON responses traditionally used? We shouldn't use SQL at all?
- laurencerowe 7y ago
  > UIs are built in trees? Take the Web's DOM as a prime example, but I think all major graphical user interfaces are primarily organized as a tree of nested components. > How so more than the RESTful JSON responses traditionally used? For generating a flat JSON object with scalar values there's a natural mapping from the single row tabular result set to a JSON object. Add an array property from a one-to-many join and you start to notice the impedance mismatch. Do you live with duplicating the scalar properties in every row of the result set or make multiple queries? The more deeply nested the JSON result the worse the problem becomes. > We shouldn't use SQL at all? SQL is fine for producing tabular results but its ubiquity means we often end up using it in situations where it's an awkward fit. Relational database are very robust and suitable for many data models so it's often a reasonable tradeoff to make. Hopefully in the future we might see a graph query language in relational databases: https://www.gqlstandards.org/ https://www.gqlstandards.org/
remify 7y ago
It looks to me that people that disregard graphql or frontend frameworks think of frontend as a place where data is just displayed not as a place where complex user interaction happen

simonw 7y ago

This is one of the most convincing arguments I've seen for GraphQL as a language for supporting UIs: that UIs map to trees, and trees aren't nearly as clean in SQL than they are in GraphQL.

tester756 7y ago
I don't understand I've been messing with trees in C# with EF Core + MSSQL and it correctly maps schema like Id, Name, ParentId (nullable) into tree, and then into json

jayd16 7y ago

UIs are built in trees? How so more than the RESTful JSON responses traditionally used? We shouldn't use SQL at all?

laurencerowe 7y ago
> UIs are built in trees? Take the Web's DOM as a prime example, but I think all major graphical user interfaces are primarily organized as a tree of nested components. > How so more than the RESTful JSON responses traditionally used? For generating a flat JSON object with scalar values there's a natural mapping from the single row tabular result set to a JSON object. Add an array property from a one-to-many join and you start to notice the impedance mismatch. Do you live with duplicating the scalar properties in every row of the result set or make multiple queries? The more deeply nested the JSON result the worse the problem becomes. > We shouldn't use SQL at all? SQL is fine for producing tabular results but its ubiquity means we often end up using it in situations where it's an awkward fit. Relational database are very robust and suitable for many data models so it's often a reasonable tradeoff to make. Hopefully in the future we might see a graph query language in relational databases: https://www.gqlstandards.org/ https://www.gqlstandards.org/

remify 7y ago

It looks to me that people that disregard graphql or frontend frameworks think of frontend as a place where data is just displayed not as a place where complex user interaction happen