Graphqlbundle: Simplify mutation definition

[ooflorent]

Defining mutations currently requires the definition of 3 blocks: the builder, the input and the payload. This proposed syntax simplifies the definition and is easier to understand (in my opinion):

Mutation:
  type: object
  config:
    fields:
      introduceShip: 
        builder: IntroduceShipMutation # Here is a BC break.
                                       # Since we haven't reach 1.0, it is not an issue.

IntroduceShipMutation:
  type: relay-mutation
  config:
    inputFields: # Define the input
      shipName: {type: String!}
      factionId: {type: ID!}
    outputFields: # Define the payload
      ship: {type: Ship}
      faction: {type: Faction}
    mutateAndGetPayload: "@=resolve('my_mutator', [value])"

mutateAndGetPayload replaces the resolve on introduceShip.

[mcg-web]

The GraphQL Relay Mutation js implementation look like returning a simple Field definition. So why not directly use Mutation Field builder with some config?

Mutation:
  type: object
  config:
    fields:
      introduceShip: 
        builder: Mutation
        builderConfig:
          inputFields: # Define the input
            shipName: {type: String!}
            factionId: {type: ID!} 
          outputFields: # Define the payload
            ship: {type: Ship}
            faction: {type: Faction}
          mutateAndGetPayload: "@=mutation('my_mutator', [value])"    

[ooflorent]

I don't like what you're proposing. If Mutation has a lot of mutation fields, then it's not possible to split then into multiple files.

[mcg-web]

OK I understand the need. That also mean that we can now define custom field definition separated from system types, so it become reusable. We can generalize this to all field builder...

[akomm]

My __relay__ mutation config looks like that:

saveProject:
  builder: 'Mutation'
  builderConfig:
    name: 'SaveProject'

saveWorkflow:
  builder: 'Mutation'
  builderConfig:
    name: 'SaveWorkflow'

With this You would only have to write this:

saveProject:
  type: 'Mutation'
  name: 'SaveProject'

saveWorkflow:
  type: 'Mutation'
  name: 'SaveWorkflow'

The implementation is domain specific though. I did not force it to be super generic. Still, you might want to use the idea to somehow make a generic solution out of it. If you want I can post you some code. But it also includes mapping arguments to DTOs (data transfer objects) which are automatically validated when you attach constraints on them (annotation). It also include some generic resolver that then redirects to a specific mutations handler.

Basically: following relay convention, you only need

1. a name for the mutation and
2. a field name

Out of this information you can imply the requirement for a 'SaveWorkflowInput' and 'SaveWorkflowPayload' type. You can define them as types separately. You have to, because that is the app specific part a generic solution can not imply for you.

[ooflorent]

Using graphql syntax would be better.

[akomm]

Yes. With the new feature recently added! :)