Hacker News Reader

Comment by handrous | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

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.

Reply on news.ycombinator.com