Nested GraphQL Mutations

[leebyron]

Please see these links by @aleksandarsusnjar

• Details document: GraphQL Mutations and Large Schemas
• Nested mutations (PowerPoint Show) (DRAFT before the meeting)

This discussion thread is for capturing feedback and ideas about this topic

[xuorig]

Just as a precision I think it's important to highlight that I don't think this statement is factual:

This does not require the spec to change, it is not going against it:

From the specification:

the resolution of fields other than top‐level mutation fields must always be side effect‐free and idempotent, the execution order must not affect the result

So allowing nested mutation would in fact require a spec change ☝️ to allow side effects to occur on any field (or certain fields depending on the proposal).

[aleksandarsusnjar]

Also do note that the client absolutely has to be aware of the importance of order, at all times, with the current spec or any modification of it. Current spec wording and/or the strictest interpretation of it do not save the client from that responsibility. They must serialize their requests accordingly and not execute them concurrently, for example (which they could).

[xuorig]

I think you meant "... but they MAY not". I am not saying that there aren't the cases to the contrary. What I am saying is that there are many perfectly valid cases for which this is an unnecessary obstacle. There is a huge negative impact of not allowing nested mutations and it does not have to exist.

Again, I hear your case, what I'm saying is, it does require a spec change. And changing non top-level fields from being idempotent to non-idempotent is a major one on my view. That is my only point here 👍

[aleksandarsusnjar]

Let's agree to that. Changing the spec is highly desirable in either case.

[xuorig]

👍 the reason I think it's important to highlight is that backward compatibility and favouring no change are two guiding principles. That does not mean the proposal is not great, it just means it needs a "higher bar of added value".

[aleksandarsusnjar]

Yep. I paid attention to these. And, yes, I'm quite aware that this needs to pass a higher bar. The added value is undeniably there, as evidenced by existing content/implementations. To avoid this taking forever I can see this being addressed in potentially a sequence of multiple "evolutions":

1. Spec wording and guidance improvements. Allow with due caution.
2. Evolve the spec allow better control of the execution sequence, in some way - I listed multiple possibilities which can build on one another.

[aleksandarsusnjar]

6.3.1 Normal and Serial Execution
Normally the executor can execute the entries in a grouped field set in whatever order it chooses (normally in parallel). Because the resolution of fields other than top-level mutation fields must always be side effect-free and idempotent, the execution order must not affect the result, and hence the service has the freedom to execute the field entries in whatever order it deems optimal.

Could be update to something like:

Normally the executor can execute the entries in a grouped field set in whatever order it chooses (normally in parallel). Because the the order of resolution of fields other than top-level mutation fields is not specified by default, the execution of nested fields must either be side effect-free or otherwise idempotent - the client may not expect any particular execution order and must not be affect by the result. Hence the service has the freedom to execute the field entries in whatever order it deems optimal.

Note:

1. Existing servers without nested mutations will not be affected by this precisely because they do not have nested mutations (i.e. nested field execution is side-effect free in the sense implied in the spec).
2. Clients of those servers (1) will not be affected because they aren't using nested mutations (because they don't exist).
3. Existing servers implementing nested mutations already ignored the present spec guidance and would be made more or entirely valid with a change as above.
4. Clients of those servers (3) are already made with corresponding expectations. Nothing would change.

A follow up change, sooner or later, may add a description of how to specify server abilities and behaviour that is non-default (i.e. not as described in the that paragraph above) and how can clients properly leverage that functionality.