4 ms·

This question does not make much sense: a GraphQL API can an often is implemented with SQL ! You could ask: why graphql instead of RESTful?

guelo 9y ago
Of course it makes sense. They're both query languages, right? Why is { project(name: "GraphQL") { tagline } } Better than select tagline from project where name = "GraphQL" Especially if the GraphQL server is just an intermediary later that ends up being translated to SQL anyway. That real answer to the parent's question is that most people don't have confidence in SQL servers's access controls.
- elnygren 9y ago
  If you're proposing that web servers should not exist and we should just expose the SQL DB via HTTP: what about when you don't have all of your data in a single database? What if I want/need Cassandra, ElasticSearch or MongoDB? An SQL DB is just one place where you have data and there are very valid reasons for using other solutions. In fact, some people might argue that you want to do everything with event sourcing / kappa and use Kafka + specialised data stores. GraphQL fits this universe perfectly. It also fits the one where you only use a single SQL DB since a GraphQL query translates quite nicely to SQL with minimal amount of code in between.
  - dragonwriter 9y ago
    Using SQL as a query language doesn't limit your choice of backend data source(s) any more than using GraphQL does.
- exogen 9y ago
  One immediate improvement: SQL queries return rows of scalars. It's very tedious to reconstruct nested objects from the resulting column aliases that are ultimately necessary (and in this case, the client would even need to do it all themselves!). Your example is simplistic in that it requests one top-level scalar, but any real API will not be like that. Try: { project(name: "GraphQL") { tagline authors { name friends { name } } } }
  - stuartaxelowen 9y ago
    Modern SQL databases like PostgreSQL offer full JSON capabilities to serve this need.
    - exogen 9y ago
      I've used its JSON support extensively and no, it's not really the same at all. What you're saying is that you're OK with (1) planning to not use columns to store your individual data fields in the first place, forgoing the primary SQL features of column-based lookup, joins, etc., or (2) having the client write complicated Postgres-specific SQL queries that dynamically construct JSON strings built from the fields that are stored in the real row structure.

guelo 9y ago

Of course it makes sense. They're both query languages, right? Why is { project(name: "GraphQL") { tagline } } Better than select tagline from project where name = "GraphQL" Especially if the GraphQL server is just an intermediary later that ends up being translated to SQL anyway. That real answer to the parent's question is that most people don't have confidence in SQL servers's access controls.

elnygren 9y ago
If you're proposing that web servers should not exist and we should just expose the SQL DB via HTTP: what about when you don't have all of your data in a single database? What if I want/need Cassandra, ElasticSearch or MongoDB? An SQL DB is just one place where you have data and there are very valid reasons for using other solutions. In fact, some people might argue that you want to do everything with event sourcing / kappa and use Kafka + specialised data stores. GraphQL fits this universe perfectly. It also fits the one where you only use a single SQL DB since a GraphQL query translates quite nicely to SQL with minimal amount of code in between.
- dragonwriter 9y ago
  Using SQL as a query language doesn't limit your choice of backend data source(s) any more than using GraphQL does.
exogen 9y ago
One immediate improvement: SQL queries return rows of scalars. It's very tedious to reconstruct nested objects from the resulting column aliases that are ultimately necessary (and in this case, the client would even need to do it all themselves!). Your example is simplistic in that it requests one top-level scalar, but any real API will not be like that. Try: { project(name: "GraphQL") { tagline authors { name friends { name } } } }
- stuartaxelowen 9y ago
  Modern SQL databases like PostgreSQL offer full JSON capabilities to serve this need.
  - exogen 9y ago
    I've used its JSON support extensively and no, it's not really the same at all. What you're saying is that you're OK with (1) planning to not use columns to store your individual data fields in the first place, forgoing the primary SQL features of column-based lookup, joins, etc., or (2) having the client write complicated Postgres-specific SQL queries that dynamically construct JSON strings built from the fields that are stored in the real row structure.