SQL is designed for rows of flat data. GraphQL is designed for nested data. It's two very different use cases. Trying to say one is better than the other completely misses the point.
That is no longer exclusively the case. SQL is used in plenty of places to query nested and semi-structured data. In fact I use it on a daily basis. Eg: avro data in/from Kafka, "json" data from MongoDB.
Do you think any GraphQL api backed by a row based data store is a mistake and should be some kind of SQL api instead? The data could be represented either way so I don't really think it matters.
No. You miss the point. SQL has proven robust over a broad set of types of data. People have tried to come up with new systems for objects (OODB), JSON documents (Mongo), and so on. All were disasters. It turned out SQL was the answer all along.
It turns out a generic tool which works well over many use-cases beats a tool which only works in one use-cases. SQL seems to be that tool.
It's possible to do nested data with SQL too.
I'll believe GraphQL is better when I see a case when it works better. So far, the only cases I've seen were from people who didn't fully grok SQL.
I'll mention GraphQL has a completely separate use-case as a replacement for RESTful APIs, where it's not really acting so much as a query language as an API layer. I think it might have some uses there, but as nedbat points out in the thread, it'd be possible to use SQL as a replacement for RESTful APIs too, and it'd probably do better than GraphQL (before you start screaming about security, read netbat's posts; he is definitely NOT talking about a thin layer over a database).
> No. You miss the point. SQL has proven robust over a broad set of types of data. People have tried to come up with new systems for objects (OODB), JSON documents (Mongo), and so on. All were disasters. It turned out SQL was the answer all along.
Document DBs have failed in the general case because most data is relational. OODB is still alive and well; Postgres implements some OODB features, and I would argue graph databases are an implementation of an OODB.
I also think you're lumping SQL and RDBMS together into one term. It's entirely possible to have an RDBMS that does not use SQL; likewise it's possible to have a system that is not an RDBMS that does use SQL. There are addons for MongoDB that let you speak SQL to it.
> I'll believe GraphQL is better when I see a case when it works better. So far, the only cases I've seen were from people who didn't fully grok SQL.
Most of the advantages come from introducing an intermediary data broker (the GraphQL server). As a query language, I do find GraphQL drastically simpler than SQL. We can compare queries for a person, their parents, and their children. I can guarantee the GraphQL query is shorter and more legible. That comes at the cost of flexibility, which I wholly acknowledge.
> I'll mention GraphQL has a completely separate use-case as a replacement for RESTful APIs, where it's not really acting so much as a query language as an API layer. I think it might have some uses there, but as nedbat points out in the thread, it'd be possible to use SQL as a replacement for RESTful APIs too, and it'd probably do better than GraphQL (before you start screaming about security, read netbat's posts; he is definitely NOT talking about a thin layer over a database).
This is the only use case that I'm aware of. There is dgraph, which is a graph database that speaks in GraphQL natively, but they've basically just integrated the API server into the database itself (which I'm not arguing for or against, I just think it's still basically the same stack).
I've written difficult and complex SQL, over a 20+ year period, along with taking a deep dive into relational theory via Chris Date. I'd say I fully grok SQL; well I'm still learning as are the majority of us who are not Chris Date. It's a vast and comolex topic, enough that there are experts specific to it for an entire career. Graphql is great because it's far simpler. I learned how to use it on the front-end in a matter of hours. And learned how to implement it on the backend in a few weeks. It's a different level of abstraction, and shields our front-end devs from many underlying complexities, including but not just the SQL.
I do see your point that for many applications you want the result in a tree, not in a list of rows. I think there should be a relational query language that lets you map from one schema to another schema (or potentially a subset of an existing schema), allowing the result to be another graph (or database in the parlance of RMDBs)
chrisjc|5 years ago
That is no longer exclusively the case. SQL is used in plenty of places to query nested and semi-structured data. In fact I use it on a daily basis. Eg: avro data in/from Kafka, "json" data from MongoDB.
je42|5 years ago
jayd16|5 years ago
wegs|5 years ago
It turns out a generic tool which works well over many use-cases beats a tool which only works in one use-cases. SQL seems to be that tool.
It's possible to do nested data with SQL too.
I'll believe GraphQL is better when I see a case when it works better. So far, the only cases I've seen were from people who didn't fully grok SQL.
I'll mention GraphQL has a completely separate use-case as a replacement for RESTful APIs, where it's not really acting so much as a query language as an API layer. I think it might have some uses there, but as nedbat points out in the thread, it'd be possible to use SQL as a replacement for RESTful APIs too, and it'd probably do better than GraphQL (before you start screaming about security, read netbat's posts; he is definitely NOT talking about a thin layer over a database).
curryst|5 years ago
Document DBs have failed in the general case because most data is relational. OODB is still alive and well; Postgres implements some OODB features, and I would argue graph databases are an implementation of an OODB.
I also think you're lumping SQL and RDBMS together into one term. It's entirely possible to have an RDBMS that does not use SQL; likewise it's possible to have a system that is not an RDBMS that does use SQL. There are addons for MongoDB that let you speak SQL to it.
> I'll believe GraphQL is better when I see a case when it works better. So far, the only cases I've seen were from people who didn't fully grok SQL.
Most of the advantages come from introducing an intermediary data broker (the GraphQL server). As a query language, I do find GraphQL drastically simpler than SQL. We can compare queries for a person, their parents, and their children. I can guarantee the GraphQL query is shorter and more legible. That comes at the cost of flexibility, which I wholly acknowledge.
> I'll mention GraphQL has a completely separate use-case as a replacement for RESTful APIs, where it's not really acting so much as a query language as an API layer. I think it might have some uses there, but as nedbat points out in the thread, it'd be possible to use SQL as a replacement for RESTful APIs too, and it'd probably do better than GraphQL (before you start screaming about security, read netbat's posts; he is definitely NOT talking about a thin layer over a database).
This is the only use case that I'm aware of. There is dgraph, which is a graph database that speaks in GraphQL natively, but they've basically just integrated the API server into the database itself (which I'm not arguing for or against, I just think it's still basically the same stack).
joshuamorton|5 years ago
tchaffee|5 years ago
smadge|5 years ago
I do see your point that for many applications you want the result in a tree, not in a list of rows. I think there should be a relational query language that lets you map from one schema to another schema (or potentially a subset of an existing schema), allowing the result to be another graph (or database in the parlance of RMDBs)