age
age copied to clipboard
apache
Initial Research for Supporting GraphQL
Initial Task to discuss the development for GraphQL Support of Apache AGE. Please comment here to be assigned to the project.
https://spec.graphql.org/October2021/
Welcome everyone so far, I have included a link to the most recent GraphQL specification that we will be attempting to implement. Please review this and leave any comments/questions issues either about that or anything else here.
Is there any specific timeline we should finish reviewing GraphQL specifications?
There is not a specific timeline. To be clear, we are not looking for you to memorize the entire standard. What we are expecting from you guys is, to look over the specification and have a general idea of how GraphQL works. Don't just look at this url. Also checkout the whole site as well: https://graphql.org/
What we need to do here is to create a dialog about how this can be implemented. There are several ideas the AGE team has on how to do it, but we want to know what you think as well. It might be useful to checkout an implementation or two, found here: https://graphql.org/code/
Hey Josh, I have a base understanding of GraphQL on the user-end side of things, at least at a high level. I'm wondering if you have some resources to better understand AGE to better grasp how this may differ from applying to a PostgreSQL or MySQL DB. This is all very new and I want to be time considerate and focus on the most important ideas before I dive deeper.
I took a look at the slides again that I saw you uploaded to the intro to AGE project.
The big take away was there are three unique types to AGE: vertices, edges and paths, with the first two being JSON data types and the later being an array/list of alternates of the former two. They are stored in AGE labels. DB complexity is something I am still tackling, so the purpose of these data types is over my head at the moment. A 15min zoom call at any time just to clarify would go a long way.
Nonetheless, we are looking to integrate GraphQL on querying and modifying these data types, that I believe are only accessed through the cypress command. And GraphQL needs an initial schema to understand the relationships of data and how to find the eventual user’s query. The issue if I’m understanding correctly is, GraphQL will interpret the cypress command like postgreSQL, as normal function calls unless we intercept it to run the Cypress command which will provide AGE’s tables(labels) and data(vertices/edges/paths). Is that correct?
We are planning a webinar for a technical explanation as to how AGE works. But there are no dates set. I suppose we could setup a meeting before that if you have a list of questions. However, I will also try to answer your questions here.
As you mentioned, there are three unique data types are used to represent entities in a graph, and there is a second aspect for how it is stored in Postgres. The second part of that presentation.
For the datatypes, the openCypher specification works in such a way that the existing datatypes in Postgres could not suit our needs. So we created Agtype, which is based on JSONB (one of postgres's two implementations of the Json standard).
The issue if I’m understanding correctly is, GraphQL will interpret the cypress command like postgreSQL, as normal function calls unless we intercept it to run the Cypress command which will provide AGE’s tables(labels) and data(vertices/edges/paths). Is that correct?
GraphQL is a query language, like cypher. We have already implemented cypher and GraphQL should not handle a cypher command.
Personally, I see two ways to do this:
- Create a function like cypher and create a second query language in AGE. The reason this works the way it does is the third section in the webinar.
- Create an API that accepts GraphQL commands and converts them to Cypher Commands, and is an intermediate between a client and the server. There may be several other ways to do it as well.
Hello Josh and everyone!
In terms of your two ways to implement the GraphQL query language, I think the first way is better because we won't need an intermediate language to run the GraphQL Language. Most of the time, I expect the query to run in the hug data. Also, if there is a bug in the Cypher, it could make the query fail to run or give an unexpected result. This makes the first method much safer because it runs as a separate component and is much easier to troubleshoot. Implementing GraphQL along with Cypher also makes an advantage of using AGE because it allows for more than one query language to be used with Graph DB.
This is my personal opinion!
Hello everyone who was assigned today. Please follow the instructions laid out above and try to catch up to where the conversation is so far. We be moving forward with more discussions shortly, but for now try to follow what has been discussed so far, ask any questions you have or give your input to the discussion.
Hi, I have a question. is there any plan for the methodology that will be used to implement GraphQL?
Hello everyone,
Sorry for the sudden change, but would you be able to join our discord server? After some discussion we determined that a GitHub issue isn't the best place for discussions and we needed a place for the team to hold conversations.
https://discord.gg/s6dpF6qZ
Also, please comment here your preferred method of communication, discord or slack. if you think another method is better, please provide it
https://www.reddit.com/r/apacheage/comments/xlgueu/which_is_better_slack_or_discord_for_project/
Looking to contribute at the development for GraphQL Support of Apache AGE project!
