3 ms·

But wait, doesn’t that directly contradict the first commenter’s next paragraph? > On the other hand, when you are the one to implement the Graphql server, it

But wait, doesn’t that directly contradict the first commenter’s next paragraph? > On the other hand, when you are the one to implement the Graphql server, it feels like writing your own database. You have to create a query plan, handle optimizations, corner cases, etc. If it’s so easy to craft any GraphQL query as an SQL query and let the RDBMS plan an execute the query, then shouldn’t it be easy to implement the GraphQL server on the backend?

tehbeard 5y ago
You're conflating a hand coded and optimized query vs. Building a system to take a tree and generate said optimized query automatically and quickly and correctly.
- tshaddox 5y ago
  I don't think I'm conflating it. jseban's comment indicates that anyone who knows how to write simple SQL queries would get no benefit from using GraphQL to consume data, which must mean that there is a simple SQL query that can be written to fulfill any GraphQL query.
  - marcosdumay 5y ago
    > there is a simple SQL query that can be written to fulfill any GraphQL query This is true (as long as you expect both queries to be simple, or allow both to be complex). But the conclusion you get up there is wrong and (obviously) does not follow from that. Creating a software that translate any one query into the other is a very difficult task.
  - charcircuit 5y ago
    Not all of the data sources for graphql may be in a single database. They may not necessarily even be stored in something that can be accessed with SQL.
necovek 5y ago
I think your point is a fair one. The distinction is that it's easy to write a contextual SQL query for any one GraphQL query when your database model closely matches your API objects. "Contextual" means that sometimes this requires a "side effect" to happen (eg. creating an index on a column in the SQL DB). Making it generic and performant at the same time is where the complexity is. It would be akin to saying how, since knowing that you might need an index in the SQL database is simple, a RDBMS could decide to create those indexes for you.

tehbeard 5y ago

You're conflating a hand coded and optimized query vs. Building a system to take a tree and generate said optimized query automatically and quickly and correctly.

tshaddox 5y ago
I don't think I'm conflating it. jseban's comment indicates that anyone who knows how to write simple SQL queries would get no benefit from using GraphQL to consume data, which must mean that there is a simple SQL query that can be written to fulfill any GraphQL query.
- marcosdumay 5y ago
  > there is a simple SQL query that can be written to fulfill any GraphQL query This is true (as long as you expect both queries to be simple, or allow both to be complex). But the conclusion you get up there is wrong and (obviously) does not follow from that. Creating a software that translate any one query into the other is a very difficult task.
- charcircuit 5y ago
  Not all of the data sources for graphql may be in a single database. They may not necessarily even be stored in something that can be accessed with SQL.

necovek 5y ago

I think your point is a fair one. The distinction is that it's easy to write a contextual SQL query for any one GraphQL query when your database model closely matches your API objects. "Contextual" means that sometimes this requires a "side effect" to happen (eg. creating an index on a column in the SQL DB). Making it generic and performant at the same time is where the complexity is. It would be akin to saying how, since knowing that you might need an index in the SQL database is simple, a RDBMS could decide to create those indexes for you.