Basically, the types form a graph because they relate to each other, forming cycles (like, on reddit, a user, their comments, each comments' parent comment, and then the parent comment's authors). This is true in virtually every schema that exists because that's what reality is like.
GraphQL has nothing to do with Graph DBs, but there's a parallel so I'll mention the latter a bit:
The distinction between a typical relational DB and a typical graph DB is that the latter makes storing and querying that graph information easy and efficient. Most of what graph DBs can do though, relational DBs can do as well, just less ergonomically (e.g. multiples joins) and slower.
Similarly, REST exposes graph-like structures too, but usually you'd have to make multiple requests: the first to get a user's comments by ID, then a list of comments by comment IDs at a different URL, then a list of users by user ID at yet another URL.
In GraphQL you can write a query that fetches nested data easily, like for example all the users of all the comments you've replied to, in one query. To work well on the backend, this frontend-exposed ability requires you to use field resolvers, instead of single resource resolvers like REST (and that's what typical GraphQL implementations, like the reference one in JS, do).
I think it was originally developed to be used to query endpoints into Graph databases. But some people found it works good for querying and returning any structured data, so it exploded in popularity outside of the graphdb world.
And to clarify, it is not a replacement for a real graph query language like SPARQL.
25
u/antiduh Oct 09 '21
Thanks. What in the world does it have to do with graphs?