I'm not sure how to explain something like that to a 5 year old but GraphQL is just a specification to request information. It describes a language you can speak to a GraphQL backend. I'll try that anyway!
The backend (mother/father) reads the query (your phrase) and they gives you what you want, for example they know about a lot of books and their authors, amount of pages, etc. You want to have a list of titles of books written by George von Devto but you don't care about the amount of pages in them. So instead of asking your mom/dad to just give you the books and filter the data by yourself (exclude anything but author:"George von Devto", exclude the pages count from the data), you only ask them for the titles and they do that for you. That's how it works. At least that's how I understand GraphQL.
Yes. It's an abstraction level for any data, it doesn't matter if it's a database or something else. As long as your code returns the data someone requested, you're fine. ☺
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.
I'm not sure how to explain something like that to a 5 year old but GraphQL is just a specification to request information. It describes a language you can speak to a GraphQL backend. I'll try that anyway!
The backend (mother/father) reads the query (your phrase) and they gives you what you want, for example they know about a lot of books and their authors, amount of pages, etc. You want to have a list of titles of books written by George von Devto but you don't care about the amount of pages in them. So instead of asking your mom/dad to just give you the books and filter the data by yourself (exclude anything but
author:"George von Devto", exclude the pages count from the data), you only ask them for the titles and they do that for you. That's how it works. At least that's how I understand GraphQL.So can I see it as an abstraction layer for any (supported) database?
Yes. It's an abstraction level for any data, it doesn't matter if it's a database or something else. As long as your code returns the data someone requested, you're fine. ☺
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.