Some graphql queries don't even hit the database. For example, it might reach out to a vendor endpoint to fetch data from them.
Some of our graphql mutations touch many tables, and do things besides update tables, like refreshing cache. Having used SQL for 20+ years, graphql sure feels like a higher level abstraction, especially when you want JSON hierarchical data from several tables.
There are many utilities which use SQL for querying logs, filesystems, processes ...
GraphQL could have based its language on SQL, but hierarchical queries are clumsy. For example our golang datamapper query
sql, args := JSQL("SELECT b, c").
Many("f", `SELECT g, h FROM f WHERE id= $1`, 4).
Many("x", `SELECT id, y, z FROM x`).
From("a").
Where("id =$1", 4)
ToSQL()
converts to this SQL which returns JSON
expected := `
SELECT row_to_json(dat__item.*)
FROM (
SELECT
b,
c,
(SELECT array_agg(dat__f.*) FROM (SELECT g,h FROM f WHERE id=$1) AS dat__f) AS "f",
(SELECT array_agg(dat__x.*) FROM (SELECT id,y,z FROM x) AS dat__x) AS "x"
FROM a
WHERE d=$2
) as dat__item
`
The equivalent GraphQL query is certainly more elegant.
> Some graphql queries don't even hit the database.
Except in the sense that the SQL engine is itself part of a database server, that's easily true of SQL queries in an engine that employs FDWs (or, potentially, even store procs, depending on what I/O facilities are available to them), which can also reach to a vendor endpoint and fetch data transparently to the client.
Some of our graphql mutations touch many tables, and do things besides update tables, like refreshing cache. Having used SQL for 20+ years, graphql sure feels like a higher level abstraction, especially when you want JSON hierarchical data from several tables.