Hacker News Reader

Comment by tgtweak | Hacker News Reader

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.

View on HN

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.

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.

That's an interesting point. The beauty about SQL is that behind it, it has really good backed theory of Codd's Relational Algebra. Whereas Document Based, Column Based and GraphQL, don't have that. It would be interesting to see research on Graph theory as data sets and how to represent them as a formal query language. The majority of Graph theory I remember taking in my CS classes (granted, that was more than 15 years ago) was about graph traversal and path-finding.

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.

Or use Odata: rest, with all the benefits of graphql, and aggregations, grouping, joins, filtering, sorting.

I wonder how much of that naming has to do with FB's Open Graph APIs.

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).

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.

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.

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).

To me, the best part about graphql is subscriptions over websockets.

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/ 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.

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

Dgraph was built around GraphQL and natively supports it.

Reply on news.ycombinator.com