Mutation delegates, middleware or hooks for true modularisation

[harm-less]

Hello,

I'm thinking about using this library, but I ran into a puzzle that I'm not sure is already solved. Or maybe I'm thinking about it all wrong...

But imagine the following modules: Chats and Messages. In the Messages module a Chat type is extended so it has messages. The final schema could look like this:

type Chat {
  id: Int!
  messages: [Message!]!
}
type Message {
  content: string!
}
mutation {
  deleteChat(id: Int!)
}

Of course in the Chats module I write a resolver for the deleteChat mutation, but the Chats module doesn't know about the Messages module. In the resolver I can delete the chat I want to delete, but what's the recommended way to delete the messages that are related to the chat I deleted? Because I want to do this from the Messages module to keep true modularisation of course.

[harm-less]

To go a bit more in depth about a possible solution/work-around I've in mind.

I'm going to use TypeORM, so it's going to use an ORM but I don't want to use features that automatically delete the relation data as I'd like to keep control over that.
I'm thinking about using a queryrunner (transaction) from TypeORM and starting a transaction from either an injectable or directly from the deleteChat resolver. Within this transaction I might use a hook library like before-after-hook so I can pass the queryrunner and other data along to modules listening to this hook.

Other modules can hook into this, well... hook, and use the before and after methods to handle specific logic.
But at least this way additional validation, throwing errors or mutation logic is handled in modules where it should.

I can't probably find a way to wrap all this in an injectable provider to keep using the features from GraphQL-Modules and pass the hooks around. And secondly to keep the API simple to use and pass around.

And I get to keep my type definitions as before-after-hook plays well with TypeScript.

All feedback is welcome, thanks!

[smolinari]

You might get more discussion on Discord. https://discord.com/channels/625400653321076807/631489781724872736

😃

Scott

[harm-less]

Thanks, I'll check it out, but the link doesn't work. I don't end up in any channel @smolinari

Edit: Ah, I found it through the guild website 👍

[onhate]

The approach I would take on this is as follow:

chats module:

type Chat {
  id: Int!
}
mutation {
  deleteChat(id: Int!)
}

messages module:

extend type Chat {
  messages: [Message!]!
}
type Message {
  content: string!
}

now, here comes the trick, on deleteChat mutation you will need to trigger an event that messages module will listen to delete the messages, in that way the chat modules keeps not knowing about messages module, it only triggers a generic event ChatDeleted.

pseudo code, not actually tested

const resolvers = {
   Mutation: {
       deleteChat(_, {id}, {injector}) {
           // ... delete the chat
           // now, this could happen in  many ways, on AWS for example I would send an SNS message and have a lambda listening to that
           injector.get(PubSub).publish('Chat:Deleted', { id }); 
       }
   }
}