No, I disagree.
GraphQL is definitely a query language,
since it allows to specify pieces of data to be extracted from a whole data set.
Compared to SQL,
this is done using an unusual manner,
giving a shape of the data we want around some seed,
but the approach is both expressive and efficient.
In light of this query principle,
it is perhaps unfortunate that GraphQL use a different syntax for the query and the response.
To this regard, freebase's MQL is more pure
(http://wiki.freebase.com/wiki/MQL).
About graph, I think the term applies too.
Indeed, a GraphQL defines a subgraph to be extracted from a whole graph,
even if the tree shape of the response forces to resort to ids to tie the loop.
Compared to a graph traversal query language like Gremlin
(https://en.wikipedia.org/wiki/Gremlin_%28programming_languag...),
I find the pattern approach of GraphQL simpler to grasp;
and even easier to implement efficiently in a distributed setting.
I implemented years ago a distributed graph database for Yahoo!;
and the query language, based on shapes to be extracted around seeds,
was a key design choice for an efficient architecture and short query delays.
Compared to SQL, this is done using an unusual manner, giving a shape of the data we want around some seed, but the approach is both expressive and efficient. In light of this query principle, it is perhaps unfortunate that GraphQL use a different syntax for the query and the response. To this regard, freebase's MQL is more pure (http://wiki.freebase.com/wiki/MQL).
About graph, I think the term applies too. Indeed, a GraphQL defines a subgraph to be extracted from a whole graph, even if the tree shape of the response forces to resort to ids to tie the loop.
Compared to a graph traversal query language like Gremlin (https://en.wikipedia.org/wiki/Gremlin_%28programming_languag...), I find the pattern approach of GraphQL simpler to grasp; and even easier to implement efficiently in a distributed setting. I implemented years ago a distributed graph database for Yahoo!; and the query language, based on shapes to be extracted around seeds, was a key design choice for an efficient architecture and short query delays.