A naive question here. (I'm in a bar and didn't fully read the docs): how can I leverage GraphQL (or sangria in specific) to existing graph databases / computation engines. Namely: is there a way to implement a GraphQL adapter for GraphX (Spark's graph library) or Titan / Neo4j?
From a first glance GraphQL looks better than Gremlin (no offense)
Can I treat GraphQL as going toward being a "better tinker pop"? If not than what are the use cases for GraphQL in the context of existing graph databases?
No. They're basically totally unrelated despite the name. GraphQL is a way to build and query a typed API that exposes nested resources. It's an alternative to REST. There is no graph computation happening. I'd view it as a more flexible version of REST with types.
"
GraphQL is a query language designed to build client applications by providing an intuitive and flexible syntax and system for describing their data requirements and interactions.
GraphQL is not a programming language capable of arbitrary computation, but is instead a language used to query application servers that have capabilities defined in this specification. GraphQL does not mandate a particular programming language or storage system for application servers that implement it. Instead, application servers take their capabilities and map them to a uniform language, type system, and philosophy that GraphQL encodes. This provides a unified interface friendly to product development and a powerful platform for tool‐building."
This is very different goal that most graph query languages.
Nothing stops you from integrating GraphQL with your graph database and I know that people are already working on it.
But it isn't a way to specify graph queries, e.g. you can't express concepts like "find the shortest path from vertex A to vertex B using edges with the given label". It's just not designed for that kind of thing.
It's very neat stuff (it saves on multiple round trips to collect just what your UI needs right now), but GraphQL isn't about graphs (although one of my primary use cases does use an underlying graph database), just like React isn't reactive.
I think Facebook's naming people do this on purpose. (j/k)
Comments
A naive question here. (I'm in a bar and didn't fully read the docs): how can I leverage GraphQL (or sangria in specific) to existing graph databases / computation engines. Namely: is there a way to implement a GraphQL adapter for GraphX (Spark's graph library) or Titan / Neo4j? From a first glance GraphQL looks better than Gremlin (no offense)
Can I treat GraphQL as going toward being a "better tinker pop"? If not than what are the use cases for GraphQL in the context of existing graph databases?
No. They're basically totally unrelated despite the name. GraphQL is a way to build and query a typed API that exposes nested resources. It's an alternative to REST. There is no graph computation happening. I'd view it as a more flexible version of REST with types.
"It is a query language for graph data..." is directly from their description.
https://facebook.github.io/react/blog/2015/05/01/graphql-int...
Yeah, except if you look closely at what GraphQL actually is that description is very misleading.
The spec has a better description: https://facebook.github.io/graphql/#sec-Overview
" GraphQL is a query language designed to build client applications by providing an intuitive and flexible syntax and system for describing their data requirements and interactions.
GraphQL is not a programming language capable of arbitrary computation, but is instead a language used to query application servers that have capabilities defined in this specification. GraphQL does not mandate a particular programming language or storage system for application servers that implement it. Instead, application servers take their capabilities and map them to a uniform language, type system, and philosophy that GraphQL encodes. This provides a unified interface friendly to product development and a powerful platform for tool‐building."
This is very different goal that most graph query languages.
Why not? Maybe it is not possible currently, but what stops me from creating a graph databases optimised for these types of queries?
Currently a lot of research is being done on graph databases, and they can be potentially faster for queries that normally take a lot of joins.
Nothing stops you from integrating GraphQL with your graph database and I know that people are already working on it.
But it isn't a way to specify graph queries, e.g. you can't express concepts like "find the shortest path from vertex A to vertex B using edges with the given label". It's just not designed for that kind of thing.
Ah... Lots of promise in the name though :) I was optimistic.
It's very neat stuff (it saves on multiple round trips to collect just what your UI needs right now), but GraphQL isn't about graphs (although one of my primary use cases does use an underlying graph database), just like React isn't reactive.
I think Facebook's naming people do this on purpose. (j/k)