Enable constraints/filter conditions used to calculate Aggregate filters

[imkleats]

Is your feature request related to a problem? Please describe. Address disparity between ability to apply constraints (i.e. filter conditions) on *Aggregate fields but not being able to apply similar constraints/filter conditions within *Aggregate filters on the parent type.

Example: Given there are Groups that have Posts authored by Users, and some Users have a special characteristic of being an Administrator, suppose that you want to apply a filter that will return all Groups where there are fewer than 10 posts (or any other arbitrary number) written by Users who are Administrators.

Current Limitations

• We can query by the number of Posts in a Group.

query {
  groups(where: {
    postsAggregate: {
      count_LT: 10
    }
  }) {
    ...groupSelectionSet
  }
}

• We can query for the Aggregate count of Posts that meet a certain condition in a Group:

query {
  groups {
    ...groupSelectionSet
    adminPostAggregate: postsAggregate( where: {
        author: {
          role: "Administrator"
        }
    }) {
       count
    }
  }
}

• But we can't apply the conditions of the second aggregate to the filter being applied to the first aggregate.

Desired Experience

• We can apply constraints used in calculation of the Aggregate value used for our filtering:

query {
  groups(where: {
    postsAggregate: {
      count_LT: 10
      where: {
        author: {
          role: "Administrator"
        }
      }
    }
  }) {
    ...groupSelectionSet
  }
}

• A more common use-case might be any time you're trying to use an Aggregate filter in the context of related nodes that have a logical delete instead of a hard delete.

Describe the solution you'd like

• Add a where input field to the generated <Type 1><Type 2>AggregateInput type that is of type <Type 2>Where to add constraints to the aggregate calculation that <Type 1> is being filtered against.
  • This would be consistent with the API established in the existing <Type 1><Type 2>AggregationSelection's where argument, which is also of type <Type 2>Where.

Describe alternatives you've considered We're using middleware to apply the constraints ourselves in an intermediate step that reduces an extended <Type1><Type2>Aggregate input (with the where argument added) into a list of IDs that can replace the original Aggregate filter field with a <field>: { id_IN: [<list of IDs>] } condition, which adds a round-trip to the database and isn't scalable when the number of matching IDs is large.

Additional context Happy to address any additional necessary clarification or context in replies