Graphql-js: Official aggregation syntax for GraphQL?

[matthewgertner]

Are there any official plans to add an aggregation syntax to GraphQL that can be used to group results, calculate aggregate values (average, max, total, etc.) and the like? This could be done as part of the GQL schema like https://github.com/blueflag/graphql-aggregate or as a separate aggregation pipeline a la MongoDB.

We are currently not sure whether it makes sense to port over some of our legacy web APIs since the expressive power of GQL itself is not enough for our purposes (e.g. retrieving only items from a collection that have a unique value for a certain property).

Anyway this strikes me as a natural extension to the current spec and I'm curious to know whether there are current plans or, if not, whether this is something that might potentially be tackled in the future or is considered to be definitively out of scope.

[wincent]

We are currently not sure whether it makes sense to port over some of our legacy web APIs since the expressive power of GQL itself is not enough for our purposes (e.g. retrieving only items from a collection that have a unique value for a certain property).

Can you provide a bit more detail about this use case? It sounds like the kind of thing that could be handled via field arguments (eg. someField(prop: "value") or similar).

[matthewgertner]

For example, we have one query where we retrieve a bunch of foos that have a bar property. We only want one foo for each value of bar.

I agree that we can implement this in a way specific to our domain using field arguments, and that may be the best approach. By concern is that we may need to version the API in the future if we tie the behavior too closely to the specifics of our domain. I would prefer a generic syntax that would allow us to express this behavior as an aggregation (group by bar then take the first item in each group). That way if we change the query in a future version of the app, the old version would still work.

Having researched this a bit further, I gather that this is fundamentally counter to the GQL philosophy, as it seems explicitly _not_ to want to be a database query language.

[leebyron]

It's likely out of scope. One of the principles of GraphQL is to ensure schema developers are able to only expose what is performant, and the aggregation functions are often a hidden source of complexity, where it's unclear how much data is loaded to fulfill them.

Typically this kind of thing is provided directly within the schema itself. For example:

{
  foos { bar }
  uniqueBarFoos { bar }
  maxBarFoo { bar }
}

[matthewgertner]

Thanks, @leebyron. There's a clear tradeoff by having this stuff defined at the domain level (i.e. status quo) and having it at the database level (much more flexibility but increased implementor burden, etc.). I wouldn't be surprised to see the balance shift over time but for now we'll stick with the domain-level approach and put the aggregated collections in the schema as you suggest.