Add mutations to apollo server

[mark-prins]

Add some mutations to Apollo server to enable editing / adding / deleting entities.

Expected Behaviour

Should be able to edit (CRUD) an entity via the API

Possible Solution

• Proposed Schema

  type Mutation {
  createEntity(entity: EntityInput): UpdateMutationResponse
  deleteEntity(code: String!): DeleteMutationResponse
  updateEntity(entity: EntityInput): UpdateMutationResponse
  }

  UpdateMutationResponse is just a success code and entity object

  • deleteEntity
  • deletes a specific entity and all children and linked properties. Initial POC using upsert in RDF format ( 7b75b360c782ed26ef1d963b23161b04d490e602) - would be nicer if we could use uid(Entity) . to remove everything rather than specifying each predicate, but this currently doesn't work as dgraph.type is not set on any of our nodes - probs should be addressed in a separate issue)
• createEntity
  • Generates code in backend - probably not ideal for users to be making codes up.
  • Probably ok for this to be relatively free form - i.e. not restrictive on what hierarchy someone can specify
• updateEntity
  • Requires code to lookup in backend before updating, if no match, throw error
• All mutations - only allow if user is authenticated for now

[wlthomson]

Not sure if this is just a placeholder for later... but just in case!

IIRC in we don't want to demo mutations for v2 in this sprint? I feel like this is only going to be worth getting into v2 if we can implement authentication + a UI for creating/updating/deleting entity data. Given only a couple of days left, might be good idea to focus on clearing out the review backlog (some of which my fault, but I'm sickly so you can't pick on me).

[mark-prins]

yeah, a placeholder. I was putting the WIP which I'd done in testing the back-end auth into a branch before heading into the murky thicket of PRs-vlille.

[wlthomson]

Oops! Sounds good!

[kat-ms]

Update: Brain dumped thoughts so far into Possible Solution (for my own future reference and anyone curious/wanting to provide input).

[mark-prins]

@katherine-sussol that looks good!

An additional thought: we're heading toward approvals / drafts and perhaps we could consider soft-delete at some point? I'm not sure that it is required for this project, it was just the comment of deleting a node and all properties & children.. that made me nervous.

If the code is autogenerated, we cannot recreate an accidentally removed node - so perhaps a soft-delete and restore will be needed.

[kat-ms]

Yeah, soft-deletions are probably a good idea, full deletion is pretty final (and maybe best left as an extra-final thing someone can do periodically to clean up soft-deleted nodes).

Thinking we could add a 'deleted' flag to entities? Or create a deleted node and link deleted items as children? Or maybe there are other options... 👀 📚: