Take codegen depth as an input to @model

[edwardfoyle]

Is your feature request related to a problem? Please describe. There are lots of cases where a model is self-referential and the entities have a bi-directional relationship. Eg. posts with comments where each comment has a reference back to the post. When queries and mutations are generated for these models, the return objects can be unnecessarily nested.

Describe the solution you'd like Be able to define optional codegen depth on a per-operation basis that will override the global default. The following is an example @model SDL where this behavior would be specified

directive @model(
  queries: ModelQueryMap,
  mutations: ModelMutationMap,
  subscriptions: ModelSubscriptionMap
) on OBJECT
input ModelMutationMap { create: String, update: String, delete: String, createDepth: Int, updateDepth: Int, deleteDepth: Int }
input ModelQueryMap { get: String, list: String, getDepth: Int, listDepth: Int }
input ModelSubscriptionMap {
  onCreate: [String]
  onUpdate: [String]
  onDelete: [String]
  level: ModelSubscriptionLevel
}
enum ModelSubscriptionLevel { off public on }

And then it could be used in the following way:

type Comment @model(queries: {getDepth: 4, listDepth: 5}) {
  id: ID
}

to generate get queries with a depth of 4 and list queries with a depth of 5.

Describe alternatives you've considered Specify a reasonable codegen depth for the current project and create custom queries / mutations for any operations where this default doesn't work. This creates unnecessary work making sure these custom queries stay in sync with the rest of the project.

Another option that seems like it may solve most use cases is to ignore the "items" field in the depth count when generating queries for one-to-many relationships. Based on discussion in aws-amplify/amplify-cli#1013 this would generate code that is closer to developer expectations. However I would not say this is the same feature because there still may be cases where you have some models that are deeply nested and others that aren't.

Additional context There have been some other related requests made aws-amplify/amplify-cli#1013, but they all seem to target trying to come up with more sensible defaults whereas this gives the developer total control to adjust depth for each operation. Another related issue is aws-amplify/amplify-cli#2977.

[andrestone]

I'd love to see this implemented.

[dtelaroli]

+1

[hanna-becker]

This would be so useful! There is no one-size-fits all w.r.t statement depth in most applications. Choosing a deep level and using auto-generated statements makes our app slow. Plus, we run into an issue with nested field-level @auth properties that we now remove from the queries with an amplify hook and complicated regexes. We also tried hand-creating queries, but maintaining them is a nightmare.

[james-e-morris]

I wrote a bash gist that helps with this issue by running codegen configure before codegen, while also printing out the suggested configure settings before the prompt. https://gist.github.com/Morrious/577c57621d27498103996f63ec209ebc

Fixing this Issue would make my life so much easier and require zero user input during the codegen. I currently generate graphql files of depth 2, 3, and 4 for different use cases in my application. These need to be regenerated every time I make a change to my schemas.

[karsenkeith]

Would love to see this as well. Is there any idea if this would be picked up in the near future?