Provide the ability to generate queries/mutations/subscriptions to different depths

[pr0g]

Describe the feature you'd like to request

Currently in Amplify there is a setting in graphqlconfig.yml under the extensions/amplify section called maxDepth which controls the depth of queries to generate for GraphQL queries, mutations, and subscriptions:

extensions:
  amplify:
    codeGenTarget: typescript
    generatedFileName: src/API.ts
    docsFilePath: src/graphql
    maxDepth: 4 <---- # this value

Due to the recent change to mutations and subscriptions to not allow relationships to be returned unless the authorization matches exactly, it is possible for mutations to fail and report the error:

"message": "GraphQL error: Cannot return null for non-nullable type: 'ID' within parent '<NestedModel>' (/update<Model>/<NestedModel>/id)

If the relationships are removed, things work as expected. It would be very convenient to be able to granularly control the depth of queries for mutations/queries/subscriptions separately (e.g. queries maybe set to say 3 or 4, and subscriptions and mutations set to 1).

Describe the solution you'd like

A solution like this might be useful to independently control mutations/subscriptions/queries:

extensions:
  amplify:
    codeGenTarget: typescript
    generatedFileName: src/API.ts
    docsFilePath: src/graphql
    maxQueryDepth: 4
    maxMutationDepth: 1
    maxSubscriptionDepth: 1

Or maxDepth could only apply to queries and not subscriptions and mutations by default, unless some other setting is applied or an override is set.

This is just an idea, there might be a better way to solve the problem.

The unfortunate issue today is if you have a relatively large maxDepth set (we use 4 right now), in many cases this makes default generated mutations (which up until recently have been very useful) essentially unusable given the problem described above.

Describe alternatives you've considered

This workaround described by @chrisbonifacio is a good stop-gap, but a bit clunky to rely on long-term.

Another alternative is to rely on creating custom mutations and to manually remove the nested types (relationships) as mentioned here, however this does somewhat negate the utility of the codegen for mutations.ts so would be nice to avoid if possible.

Additional context

See https://github.com/aws-amplify/docs/pull/7768/files which describes the recent change to mutations/subscriptions.

Is this something that you'd be interested in working on?

• [ ] 👋 I may be able to implement this feature request

Would this feature include a breaking change?

• [X] ⚠️ This feature might incur a breaking change

[dpilch]

We are investigating options so that the errors will not be present in the response. This may be done with setting different depth for some statements, but we are still researching other options.

[pr0g]

Understood, thank you for the update @dpilch 👍