[TheMakeA]

Every time there's a new post about GraphQL, I become even more concerned that "GraphQL" was the wrong name to use publicly. It seems like most people assume it's just another combination of two buzzwords, Graph and QL, and incorrectly pattern match it.

In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead.

It's not a storage layer. It's not really a query language. It's an alternative way to define an API that more closely matches the typical mental and product domains than REST.

It's critical to realize that you're implementing an API. GraphQL does not concern itself with sorting or fetching data as the name might lead you to initially believe. It has little to actually do with graphs (except they are more easily expressed). It is designed to be added on top of your application layer and business logic to provide a single, well defined API for your product and tools.

It primarily targets product developers. From the scheme/API side, it is up to the server developer to decide what to expose and how, based on the product and any technical considerations that need to be made.

[dwenzek]

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.

[TheMakeA]

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.

[dwenzek]

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.

[cbsmith]

  In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead.
  
  It's not a storage layer. It's not really a query language. It's an alternative way to define an API that more closely matches the typical mental and product domains than REST.

That is a tremendous and useful insight.

[devit]

I think "ObjectQL" or "NestedRPC" might be more appropriate: it's an IDL and protocol for a nested RPC facility for object-oriented systems.

You start with a root query object and then call a bunch of methods on it of the client's choice and put the results in a dictionary.

Then you do that recursively on the resulting objects until you have data consisting of nested dictionaries and lists containing only primitives, which is finally serialized as JSON and returned.

[andy_ppp]

GraphQL:

1) Give me data in the right shape for my problem please server.

2) Server responds with data in a shape that matches what it was asked for.

3) Update the store of your frontend and trigger any updates to UI (react does this automatically).

Save countless hours of writing fine grained rest APIs to support various different ways of requesting data or munging data into the right format on the client.

And by the way we've made it super easy to bundle requests together in a nice way saving trips to the server.

[adriancooney]

I'd have to disagree in that it's not a query language, there is definitely ability to query different parts of the data. I'm just unsure where the Graph part of the name came from. I was under the impression it was some play on the words sounding like "graphical" since the appearance of the query language in code is a very close depiction of the actual data returned.

[TheMakeA]

> I'd have to disagree in that it's not a query language, there is definitely ability to query different parts of the data

For sure. If I could still edit the post, I would probably change it to be something closer to "it's not really a general purpose query language like the name might imply"

It's definitely a query language, but folks start looking for the sorting/filtering/etc and get confused.

[Amrinder12345]

Every time there's a new post about GraphQL

[eggie]

And with good reason. I work on graph data structures and have had four people suggest I check out "GraphQL" for my work. Alas it has almost nothing to do with graphs. Every time I read about it I feel that Facebook tech has jumped the shark. I'll go back to my terascale rank/select dictionaries now...

[aikah]

> Every time I read about it I feel that Facebook tech has jumped the shark

No, Facebook does it on purpose, just like React has nothing to do with functional reactive programming. They are talented , not idiots , they know that a catchy name is useful to promote their tech even if it is misleading.