5 ms·

Strange that this paper doesn't even _mention_ GraphQL.

simongray 5y ago
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.
- oliyoung 5y ago
  you're right, on every point
- topicseed 5y ago
  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/ https://dgraph.io/docs/query-language/graphql-fundamentals/
- AtNightWeCode 5y ago
  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.
contravariant 5y ago
Probably because GraphQL (despite it's name) isn't made for querying graphs.
- slver 5y ago
  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.
  - contravariant 5y ago
    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.
    - slver 5y ago
      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.
      - contravariant 5y ago
        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.
        slver 5y ago
        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.
- staticassertion 5y ago
  Sure it is. That's a major component - you can perform joins (edge traversals) across backend APIs.
p_l 5y ago
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.

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.

oliyoung 5y ago
you're right, on every point
topicseed 5y ago
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/ https://dgraph.io/docs/query-language/graphql-fundamentals/
AtNightWeCode 5y ago
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.

contravariant 5y ago

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

slver 5y ago
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.
- contravariant 5y ago
  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.
  - slver 5y ago
    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.
    - contravariant 5y ago
      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.
      - slver 5y ago
        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.
staticassertion 5y ago
Sure it is. That's a major component - you can perform joins (edge traversals) across backend APIs.

p_l 5y ago

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.