Hacker News Reader

Comment by jjgreen | Hacker News Reader

I rather like Cypher, easy to get into with the (node)-[edge]->(node) construction, difficult in the middle (until you realise that WITH is very different to SQL's), then a delight. Gremlin, so they let Java's horrible camelCase leak into their syntax? Oh my ...

View on HN

You write Gremlin in the programming language of your choice and with that comes the idioms of that language. For Java that means, camelCased syntax as that is what Java developers expect. So a function like hasLabel("person") looks right to them. In C#, that same function is HasLabel("person") and in Clojure it is (has-label :person) and so on. Gremlin isn't meant to be an embedded string within your programming language. It is actual code within your programming language.

Well I stand corrected. I was judging from the examples in the linked article, so will have another look ...

I've been using Cypher (neo4j) for a bit over a year now, and I low it. We'd need a dozen JOINs to do some of our queries in SQL, but in Cypher it's very natural to write complex relationships.

Overuse of WITH does make it a bit more imperative, but also makes it easy to shape the result in the form you want it in. Cypher has been a joy to work with. Gremlin, by comparison, does not attract me at all.

Granted, Java was one of the first programming languages I seriously learned (in university no less). The camelCase syntax became somewhat of a second nature to me, and indeed, I even internalized the idea that it simply looked better that way. I understand that syntax preferences and capitalization are mostly just preference, but are there strong arguments against the use of camelCase, or rather, in favor of something different?

If you have any opinions on GraphQL vs Cypher, I’d really appreciate it!

Context: In web app usage scenario the tooling available for GraphQL seems more popular (with react libraries) than Cypher.

Completely different use case and purpose.

Cypher is a graph query language.

GraphQL is an API query language to query tree like structures (trees...), nothing to do with graphs actually.

GraphQL can be totally be used to represent and query true graphs, not just trees. The data gets materialized into nested JSON (which can be thought of as a tree) but that doesn't mean it doesn't represent a graph.

Other than that though, you are quite correct, the two do not serve the same purpose.

Neo4j has an extension that exposes a GraphQL API that converts the queries to Cypher (https://neo4j.com/developer/graphql/#neo4j-graphql-java). I've used it for some basic things but for anything complex you need to be careful and inspect the queries it produces.

How would you query for a path or cycle of arbitrary length in GraphQL?

You cannot do that directly out-of-the box, but you can write your server to include directives for that. See some discussion here: https://github.com/graphql/graphql-spec/issues/91

Also just because you cannot query at arbitrary depths doesn't mean that GraphQL doesn't work with graphs, just that it might be a poor choice of tool for that work.

Thank you, everyone in this thread! These are some helpful insights.

DGraph is perfectly capable of doing these with a query language extremely similar to GraphQL (and as of v2 will natively support GraphQL):

https://docs.dgraph.io/master/query-language/#k-shortest-pat...

camelCase makes sense in golang's "Go Way", as minimizing variable name within its scope is promoted. Then, using underscores makes for more difficult read (words separated). CamelCase names are exported by language semantic.

So it doesn't need to be bad necessarily, if code follows the same conventions.

Reply on news.ycombinator.com