I don't know about the Graph part too (and Wikipedia doesn't know about that as well). I think the idea is that your queries kinda visualizes the data you're asking for. I mean it's not that hard to understand what I'm asking for in this query:
query {
books(author:"George von Devto") {
title
pages
comments(rating:">=4") {
name
text
}
}
}
I remember someone briefly explaining this in some conference talk, but I can't seem to find it. It has to do with how GraphQL allows you to think about and traverse your data and the relationships between them as if you're traversing nodes and edges in a graph.
It has Graph in its name because the data is structured as a Graph Data Structure, as opposed to the Linked List (i use this term very loosely) style REST APIs. The key difference is that having "nodes", as is the case for GraphQL, allows you to coalesce data from multiple "nodes" while with conventional REST API is more linear in its data retrieval.
The cool thing about nodes is that you can reference yourself (i.e the same node); it can be recursive.
Let's say you have a user object, which contains a list of friends, denoted by their UUID. We are particularly interested in the names of your friends, so what we can do is this
{user(uuid:"8f7ab4"){namefriends{uuidname}}}
What ends up happening is that in a single request we go from one user (given by a user object), get their friends list, and for each friend (also given by a user object) fetch their UUID and name. This is all made possible by how the data is structured. With a REST API, you'd have to query for each of the users by UUID, perhaps by using user/<friend-id>, returned from a user/8f7ab4/friends API call. Even more important is that the REST API call will return tons of information that you dont really care about, effectively costing you more for bandwidth and also resulting in high latency in completing the actual query you're trying to execute.
Oooh, nice!
Anyone know why it has Graph in its name? This whole time I thought it was something to do with data viz!
I don't know about the Graph part too (and Wikipedia doesn't know about that as well). I think the idea is that your queries kinda visualizes the data you're asking for. I mean it's not that hard to understand what I'm asking for in this query:
I remember someone briefly explaining this in some conference talk, but I can't seem to find it. It has to do with how GraphQL allows you to think about and traverse your data and the relationships between them as if you're traversing nodes and edges in a graph.
I think it's because you can think of each entry as a node, which has edges that connects to other nodes.
It has Graph in its name because the data is structured as a Graph Data Structure, as opposed to the Linked List (i use this term very loosely) style REST APIs. The key difference is that having "nodes", as is the case for GraphQL, allows you to coalesce data from multiple "nodes" while with conventional REST API is more linear in its data retrieval.
The cool thing about nodes is that you can reference yourself (i.e the same node); it can be recursive.
Let's say you have a user object, which contains a list of friends, denoted by their UUID. We are particularly interested in the names of your friends, so what we can do is this
What ends up happening is that in a single request we go from one user (given by a user object), get their friends list, and for each friend (also given by a user object) fetch their UUID and name. This is all made possible by how the data is structured. With a REST API, you'd have to query for each of the users by UUID, perhaps by using
user/<friend-id>, returned from auser/8f7ab4/friendsAPI call. Even more important is that the REST API call will return tons of information that you dont really care about, effectively costing you more for bandwidth and also resulting in high latency in completing the actual query you're trying to execute.Thank you! That was great.