Closed nasushkov closed 6 years ago
@nasushkov Is this https://github.com/Vincit/objection-graphql/pull/30 the better implementation?
Hi @kibertoad. First of all, this is not a mutations implementation for this library. Rather it's an extension point and doesn't break anything. Here is a new PR - #39 which allows you to provide a raw GraphQLObjectType or a builder strategy that can use current builder state as a context. Regarding #30 I would say that although it could be a sound implementation for plenty of cases I wouldn't lock with it. For instance, it doesn't work for my case. However, it can be implemented as a mutations builder strategy or even the default mutations builder strategy. But it is up to @Trellian if he is ready to update his PR. The main point here is extendability.
Hi @nasushkov Thank you for the feedback. I like your idea of making my contribution just a simple default mutations builder strategy. It gives you CRUD right out of the box, but no further customization is then easily possible. I would like to see a more generic and customizable approach than what I have proposed. I'm going to have to add some more functionality shortly, most likely custom operators, and I'd like to be able to contribute. It's a pity that @koskimas is short of time to maintain the project, he has done a great job. I'm just glad that someone is taking it forward.
I don't have much time, but I do have a need for more functionality from objection-graphql
in my current project, so I'll contribute whatever I can.
Best wishes
Added optional custom Mutations support during the build phase of the graphql schema. Since Mutations part can be quite opinionated and can heavily depend on a particular domain I would suggest that Mutations implementation should be left to the end user.