Hacker News Reader

Comment by guelo | Hacker News Reader

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.

View on HN

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.

Using SQL as a query language doesn't limit your choice of backend data source(s) any more than using GraphQL does.

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
          }
        }
      }
    }

Modern SQL databases like PostgreSQL offer full JSON capabilities to serve this need.

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.

Reply on news.ycombinator.com