Replies: 1 comment
-
When you mentioned GQL I thought you were talking about the Graph Query Language (GQL) Standard that is being developed for graph databases. Just a heads-up, if you are talking about GraphQL, then you probably need to be explicit and say GraphQL because this is probably going to get even more confusing in the future after the GQL standard is finalized. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Not sure where the effort on GQL is, but would like to raise some points about implementation.
Keeping edge functions in mind (like the ones offered by Vercel and have restricted runtime), ideally, GQL support will follow the approach taken by DGraph, rather than that taken by Neo4J.
DGraph
With DGraph, you can just hit the database via HTTP with the GQL query in the request body. Note that there is a requirement for the DB to be configured with and extended GQL schema for this to work (this can be done via the UI, or via REST, but must be configured in the DB). This paradigm allows interaction with the database using simple HTTPS requests, which are elementary with practically all lamda functions, including those on edge runtime.
Neo4J
The approach taken by Neo4J, however, is just a js library that takes a GQL extended schema and a driver and spin an Apollo server, which, looking at the code, I'm pretty sure does the GQL > Cypher conversion before firing a request to the DB. The problem with this approach is that the library and its dependency tree is a monster and is not supported on edge functions. Further, when used with edge functions, you have to recreate the driver, connection, server, per request, which is substantially more expensive than a simple HTTPS request.
Further consideration
It is generally advised to block public access to databases on security grounds. While a public GQL API (such as that offered by Github) is a valid use case, it is worth noting that this involves an elaborate authorisation setup (which the GQL layer needs to support).
In practice, I'd argue that most setups will involve a machine to DB setup, with the former responsible for query constraints and authorisation. Under such a setup (specific queries) the power of GQL is not fully utilised.
Further more, while GQL is great for simple queries, it does not have the expressive power of graph-specific query languages like SurrealQL or Cypher (I wonder why Surreal didn't choose Cypher over a DIY query language - Cypher specifications are open source, and its implementation can be very elegant if using generators - and when I've done this in JS 90% was borrowed from the Neo4J implementation).
In other words, while GQL is a great, I think this project should focus on a stable release, bug fixes, and cloud offering much more than GQL support.
Beta Was this translation helpful? Give feedback.
All reactions