Hacker News Reader

Comment by MikeTaylor | Hacker News Reader

Strange that this paper doesn't even _mention_ GraphQL.

I don't think GraphQL is used to query graph databases directly, is it? I've always understood it to be an API protocol that was built to serve some specific needs Facebook had (e.g. bundling multiple HTTP requests), not a full-on graph query language. I should probably mention that I don't really have extensive experience using it, though.

you're right, on every point

I think it is used as foundation for DQL[0], the query language of Dgraph.

But in and of itself, GraphQL isn't really built to query graph databases as you said.

[0] https://dgraph.io/docs/query-language/graphql-fundamentals/

GraphQL is basically used as SQL queries over stupid API:s. 99% of the graph DB advocates does not even understand what problem the graph DB solves. Soooo funny to argue with people when you can say that, oh, yes, we did this 20 years ago with recursive CTE:s.

Probably because GraphQL (despite it's name) isn't made for querying graphs.

Technically it is. But in a very restricted way.

Any graph, when you traverse it from a specific node, with fixed depth, and you don't explicitly work with node references, but rather node "values", looks like a tree that sprawls from that node.

Anyway, PathQuery is a completely different beast regardless.

If that counts as querying a graph then SQL is also a graph language. If anything SQL is more advanced because it can query a hypergraph.

SQL is neither a graph or hypergraph query language, because relations don't define the graph (or hypergraph). The query does. Deriving a graph and querying a graph are two different things.

A graph query language implies you're querying a graph with specific edges, not ones constructed on the fly from the query.

GraphQL's goal isn't to be "advanced" either. Its goal is to allow access to any data structure (be it backed by graph, RDBMS, file system, NoSQL, etc. etc.) without burdening said structure with capabilities that are not characteristic to it.

Like, if you query a graph, the idea the query may provide any arbitrary join expression would completely drive that graph's performance into the ground.

I can get behind the idea that SQL is a bit too powerful to allow it to talk to other databases easily.

And not automatically joining by foreign key is a mistake that's going to haunt us for a while I bet.

However when we're arguing capability then it's just as capable of querying a graph as graphDB is. More if the version of SQL supports recursive joins.

The thing I can't seem to get across to you, is that you don't query a graph by specifying a join expression. Graph databases aren't built for that. So no, SQL is not "capable of querying a graph". It's capable of deriving a graph out of relational data. Two completely different things. It's a bit like confusing a restaurant's chef with the restaurant's customer. They both have a meal in common, but one is consuming what the other is producing.

And no, arbitrary join expressions are not a feature that "haunts" SQL databases, because unlike graph databases, relational databases ARE built for that, and it's one of the primary reasons SQL databases are very resilient to change in face of constantly changing ad-hoc query requirements. And it's an important feature of relational algebra that is used every day by countless applications.

SQL and GraphQL serve different purposes at different application layers. Both do precisely what they have to do. The fact they're a bit similar is not coincidental, but also they're not mutually replaceable.

Sure it is. That's a major component - you can perform joins (edge traversals) across backend APIs.

GraphQL isn't really a comparable language, and PathQuery predates it by at least 3 years. While the paper is recent, GraphQL quite probably made zero to low impact on its topic.

Reply on news.ycombinator.com