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.
Let me clarify a little: I think the name GraphQL for sure makes sense from a technical point of view. But from a marketing point of view, it has been a nightmare and makes it _unusually_ difficult for others to initially grasp.
So what you mean is that name of GraphQL minimizes one of its important aspect:
the ability to query a service/product/app whatever are the actual persistence mechanisms
and even so if part of the response is computed on the fly.
Now, I better understand, why you would prefer a name like ProductQL
or even ProductAPI in order to emphasise the will for this tool
to be the single point of interaction from the outside with a product.
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.