Updating dependencies is deployed!
I still haven't started point 2 and 3 from the other day's list and I'm already at 92 hours (12 of the extra 20 already spent). I keep running into difficulties with either the neo4j-graphql-js library or neo4j itself when I write my own cypher queries.
For example, neo4j-graphql-js automatically generates mutations to add/remove relationships defined with the @relation directive in the schema, but I had to swap out the @relation directives for the more raw @cypher directive since the @relation directive doesn't allow us to filter soft-deleted nodes. That meant I had to write my own queries for updating relationships.
Since I've had to skip the neo4j-graphql-js library and write my own queries in many places, I've also started running into problems when those queries don't return every related node that the frontend might have asked for in the posted graphql query. For example, I might have a mutation that adds a Responsibility as a dependency to a node. The qraphql mutation returns the node and the responsibility. In graphql, I might want to also return the nodeId for the Need that the Relationship fulfills. That's easy enough to define in the graphql mutation, but it means that when I write the cypher query for that mutation in the backend I have to make sure to fetch the FULFILLS relationship for the Responsibility. Now what if I also want to fetch the guide and realizer for the Responsibility, etc, etc. It quickly gets complicated.
I think we'll need to refactor the backend and write our own resolvers (and do away with the neo4j-graphql-js library) as we continue to expand the graphql schema. That way we can set everything up so that a graphql query like the one above automatically fires off several, simple cypher queries that puzzle together the requested data. That's easy enough to do with the graphql js library on the backend if we do away with neo4j-graphql-js. Maybe it's also possible to do something similar while reusing stuff from neo4j-graphql-js, but we'd have to research that a bit. The library is still very new, so there might be undocumented features.
Sorry for the dense paragraphs, but I wanted to capture this here while it was still fresh in my mind.
Next steps:
I'll start documenting everything in the README files to make it easier for people to contribute to the project. I'm also considering if I should spend an hour or two to add the ability for users to set the "name" property for their own user in the database. Right now people who sign up are only identified by their email, although everything is built to work if a Person's "name" is set. What do you think @hugi? Would that be a good feature to have for tomorrow's workshop?
