Augment schema refactor

[michaeldgraham]

Here is a refactoring of the schema augmentation process. It augments AST data extracted from the provided schema, making sure not to overwrite any user provided types along the way. It then makes a single new schema, using the resulting augmented typeDefs and resolvers.

[YizYah]

Awesome, @michaeldgraham! I got it all to work. This is just huge. I might be able to write the article already.

But since you're directly refactoring augment schema, my front end is just begging for nested creation (and ideally other updates). I can now create extensive mutations that do create additional stuff, but how hard would it be to add the amazing things that you've got in your server package to the neo4j-graphql-js package, including:

(1) nested Create functions
(2) @model and @unique directives.

Thanks!!!!

[jexp]

I would love to have a discussion on @model directives.

I think it would be cool if @model allowed to control which mutations and queries are generated.
Which other things (e.g aliases, extra labels, ...) would make sense to configure via @model
I also want to add a @relation directive on types to represent "rich" relationships.

[YizYah]

I'm probably not appreciating the power of @model.

I actually was thinking about a unique ID identifier being generated automatically for every Type. The most useful implementation seems to me to be the following:
(1) every Type created with @model will have an ID field generated for it, as I understand is happening in this example: https://neo4j-graphql-server.gitbook.io/docs/neo4j-graphql-server#using-cypher-directives.
(2) the id will be a UUID generated automatically, as I understand happens there
(3) in the event that the id is passed as a parameter, it will override the automatic generation (@johnymontana and I chatted about this somewhere--it might even have received an issue)
(4) the ids will be globally unique across all of the types.

[YizYah]

But, as far as priorities go, my front end team is very clear that the change they want the most is nested mutations. I made the mistake of sharing @michaeldgraham's page, and now that they've seen it nothing less will do ;)

[YizYah]

I think just now I grasped @jexp 's point about @model being used for specifying which mutations are generated, and it's excellent. The problem is that some types are not made to be stored as data, but rather to be used for describing query results etc. For instance, I just created a type Path that I don't intend to be stored. So I don't want to create mutations for it.

It would be extremely helpful for us if any @model could be understood to be a stored type, and would get mutations and an autogenerated ID. Anything else would not get either. I'm telling the front end to ignore certain mutations, but it's still very confusing to them--they naturally will think when they see the schema that a Path is a stored item, which shouldn't be true at all. What's worse, they'll probably start to create them :(