Yeah, I think, in general we probably should have wrapped our queries in a response type (like we ‘wisely’ did for mutations), that would allow not having to have the aggregateData query. Doesn’t really hurt anything, just means a bit of interface bloat.
This looks like a decent approach to me.
input DataAggregateResult {
count: Int
... // Other fields for doing things like avg, sum, min, max etc.
}
query {
aggregateData(filter: DataFilter): DataAggregateResult
}
for those “Other fields for doing things like avg, sum, min, max etc.”, we’ll have to do something like either have a nested sum { ... } that contains all the fields you can sum, or do sum_fieldName to get all the alternatives. Same for count for a child. Nested seems more in keeping with what we’ve done for filters, etc.
The other way to think about it might be with some sort of @custom that allowed to add dql snippets that would be compiled into the query. That’s kinda attractive cause it’s completely generic and could support math, but would, I expect, be both harder to implement and harder to use for non dql experts.
I’l also just add my usual refrain that I see GraphQL as about an app’s data interface and not really about a query language, so I’d rather have a way to say ‘hey, add a count for this bit here’, rather than always compiling in all the possibilities everywhere.