[GitHub] [age] jasperblues commented on issue #290: Initial Research for Supporting GraphQL

[GitBox <gi...@apache.org>]

jasperblues commented on issue #290:
URL: https://github.com/apache/age/issues/290#issuecomment-1264725657

   For the purpose of general utility and attracting users to AGE, look at what users will want to do with GraphQL. The majority will be building APIs choosing it as the favored option over a REST on account of all of GraphQL's benefits. 
   
   That means they won't just want graphQL. They'll need: 
   
   * Authentication and authorization 
   * Audit / logging 
   * Custom business rules. 
   
   All of the above are typically provided by a middleware application layer. Simply have AGE expose a graphQL endpoint would deviate from this. Plus how would you specify which schema to use for which use-case(s)? 
   
   I strongly encourage for the graphQL layer to be implemented as part of the ecosystem products, outside of the main database. Doing this allows growing a bigger community around AGE with focused skillsets (same as we do with viewer) but this is not the main reason. 
   
   If we look at following Neo4j's example, they initially exposed a graphQL endpoint, then moved to having an ecosystem library, that allows integration into other middleware components - clients can use their preferred security, audit, etc. 
   
   In my view a good graphQL solution: 
   
   * Parses the schema 
   * Generate the custom CRUD automatically
   * Allow for providing custom queries and mutations for certain use-cases where the user can provide their own hand-tuned CYPHER. 
   
   In the above openCYPHER is king because : 
   
   * It is the defacto query language in the graphDB community. More is not always better. I would focus efforts on strongly adhering to the standard - giving uses confidence to join from other parts of the graphDB ecosystem. 
   * https://maxdemarzi.com/2020/05/25/declarative-query-languages-are-the-iraq-war-of-computer-science/ <-- If we look at Max's article, we can see that the reality is, on a complex mission critical app, there will be times where custom tuning of a qery will be necessary. 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@age.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org