5 ms·

I always find it amusing how much graphQL there is without actual graph db behind it. Seems the concept of having fluid relationships is appealing for querying

I always find it amusing how much graphQL there is without actual graph db behind it. Seems the concept of having fluid relationships is appealing for querying but not structuring/storing... which seems like a disconnect. I have only seen a few Neo4J systems in serious production workloads and they were ALL on logistics... I'm not sure that it's being positioned (or interpreted) as a nice simple solution to start out on. Edit: I just checked out neo4j "bloom", and it's definitely a good way to make graph more accessible - they should continue to build further on it.

jexp 5y ago
Not sure if you saw our graphql integration, that takes typedefs and converts a graphql query into a single cypher query, which can then be executed directly. https://neo4j.com/product/graphql-library/ https://neo4j.com/product/graphql-library/ has links to docs and api scaffolding tools. When I started back then in 2016 with it, it was pretty cool how directly graphql mapped to the graph model in the db.
- tgtweak 5y ago
  This looks pretty cool, directly speaks to what I was talking about re: why doesn't more of this exist.
tshaddox 5y ago
I don’t think that’s particularly amusing or a “disconnect.” From what I can tell, the entire point of GraphQL at Facebook was to expose an interface that looks like a graph database but is in fact able to load data from any number of different underlying data stores (without the query developer needing to know about that part).
- rdevsrex 5y ago
  To me, the best part about graphql is subscriptions over websockets.
handrous 5y ago
GraphQL has been such a bad name to deal with. I've seen so much "we need a graph, so isn't graphQL a good idea?" or "this is a graph database, so doing graphQL on it will be way easier & more natural than on a SQL db, right?". Even from technical and semi-technical people.
- feu 5y ago
  Is the latter not the case? I'm genuinely asking here, as this is a point of view expressed by my tech lead (though in our case it's a graph DB vs an existing MongoDB setup).
  - handrous 5y ago
    Not especially, no. It likes trees, or things that can easily and naturally be represented as trees, best, as far as I've ever been able to tell. Granted, I suppose, that's a kind of graph.
  - e1g 5y ago
    Absolutely unrelated. You can think of GraphQL as a standardized glorified RPC that calls arbitrary functions that return some data. Whether the source of data is an RDBMS, a bunch of REST microservices, DynamoDB, redis, SQLite, a flat JSON file, Neo4j, or a D12 dice doesn't really matter. The "graph" part is if your arbitrary data is actually somehow related, you can traverse those relationships in one request instead of having to do many calls in a waterfall.
- deckard1 5y ago
  This always annoyed me more than it should. It's also torturing the definition of "query language." There is no equivalent of "join", or any other typical query feature such as aggregation, grouping, sorting, filtering. GraphQL has as much to do with graphs or query languages as my smart TV has to do with intelligence. It's RPC, but RPC fell out of fashion when SOAP/WSDL/XML died.
  - zozbot234 5y ago
    Eh, many REST endpoints are de-facto indistinguishable from RPC. Though as far as a general query language for Web clients, you can use SPARQL which interoperates well with REST principles.
mrjn 5y ago
Dgraph was built around GraphQL and natively supports it.

jexp 5y ago

Not sure if you saw our graphql integration, that takes typedefs and converts a graphql query into a single cypher query, which can then be executed directly. https://neo4j.com/product/graphql-library/ https://neo4j.com/product/graphql-library/ has links to docs and api scaffolding tools. When I started back then in 2016 with it, it was pretty cool how directly graphql mapped to the graph model in the db.

tgtweak 5y ago
This looks pretty cool, directly speaks to what I was talking about re: why doesn't more of this exist.

tshaddox 5y ago

I don’t think that’s particularly amusing or a “disconnect.” From what I can tell, the entire point of GraphQL at Facebook was to expose an interface that looks like a graph database but is in fact able to load data from any number of different underlying data stores (without the query developer needing to know about that part).

rdevsrex 5y ago
To me, the best part about graphql is subscriptions over websockets.

handrous 5y ago

GraphQL has been such a bad name to deal with. I've seen so much "we need a graph, so isn't graphQL a good idea?" or "this is a graph database, so doing graphQL on it will be way easier & more natural than on a SQL db, right?". Even from technical and semi-technical people.

feu 5y ago
Is the latter not the case? I'm genuinely asking here, as this is a point of view expressed by my tech lead (though in our case it's a graph DB vs an existing MongoDB setup).
- handrous 5y ago
  Not especially, no. It likes trees, or things that can easily and naturally be represented as trees, best, as far as I've ever been able to tell. Granted, I suppose, that's a kind of graph.
- e1g 5y ago
  Absolutely unrelated. You can think of GraphQL as a standardized glorified RPC that calls arbitrary functions that return some data. Whether the source of data is an RDBMS, a bunch of REST microservices, DynamoDB, redis, SQLite, a flat JSON file, Neo4j, or a D12 dice doesn't really matter. The "graph" part is if your arbitrary data is actually somehow related, you can traverse those relationships in one request instead of having to do many calls in a waterfall.
deckard1 5y ago
This always annoyed me more than it should. It's also torturing the definition of "query language." There is no equivalent of "join", or any other typical query feature such as aggregation, grouping, sorting, filtering. GraphQL has as much to do with graphs or query languages as my smart TV has to do with intelligence. It's RPC, but RPC fell out of fashion when SOAP/WSDL/XML died.
- zozbot234 5y ago
  Eh, many REST endpoints are de-facto indistinguishable from RPC. Though as far as a general query language for Web clients, you can use SPARQL which interoperates well with REST principles.

mrjn 5y ago

Dgraph was built around GraphQL and natively supports it.