Skip to content

Nested Mutations using Type setters #182

Closed
@oojacoboo

Description

@oojacoboo

Overall, nested mutations has mixed opinions. I'm still fairly new to GraphQL and don't have a solid opinion on whether or not they have value. I think, like with most things, there are pros/cons.

Take this nice list of "rules" discussing namespaces, as an example.
https://graphql-rules.com/rules/mutation-namespaces

I'm not really sure if all, or even most, mutations should be nested as such, but I can certainly see the benefit of having nested mutations available.

Has there been any consideration for this? Could you do the following?

{
  product(id: 1) {
    disable(datetime: "2019-11-22T11:10:52+00:0")
  }
}

Assuming that'd be possible, you could leverage setters of a model/entity object without having to write custom root mutations.

There are a few downsides. Firstly, it could become abused. If someone wrote most of their GraphQL API this way, it certainly wouldn't be ideal. But, I'm not sure that's a valid reason to not support it.o

There is still a question about how persistence is handled in this case. I'm guessing you'd have to have some kind of generic controller to handle all nested mutations, at least for persistence reasons.

Another issue with nested mutations is the spec, itself. The spec states that mutations that are nested are executed in parallel. This could have adverse consequences if abused due to the order of operations. Adversely, mutations at the root are executed consecutively.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions