GraphQL Aggregation Directives

[PascalSenn]

We are currently working on a new data aggregation feature for server and client. (#4068 )

The idea for the aggregation directives was inspired by graphql-lodash
The difference between graphql loadash and this implementation, is that we want to remove the javascript semantics from the implementation. GraphQL Lodash simply maps the lodash functions into directives. This means that you can also receive [object Object] and other JS specific responses.
The implementation we do, follows a specification. All aggregations have a specific algorithm that they follow and test cases that an implementation must pass to be valid.

The aggregations are defined on a GraphQL Query, but are executed on json documents. They are not bound to the type system or the types of fields.

A major difference between graphql-lodash and this implementation is, that there is not just one directive with arguments per operation, but a directive per operation with N arguments.
This adds more flexibility in evolving the directives further.

You can checkout the specification here: https://pascalsenn.github.io

Stitching
These directives maybe be used in the future to simplify type extensions and schema rewrites in stitching

extend type Foo {
    bar: Bar @delegate(...) @map(key: "deep")
}

Discussion

1. At the moment the key argument of map countBy is just a string. It could also be a Path. so that you could select fields deeper in the tree
   Currently this can be done with multiple map declarations:

{
   locationOfSpeakers : sessions @map(key: "speaker") {
      speaker @map(key: "address")  {
          address @map(key: "city") {
             city
         }
      }
    }
}

with the Path scalar it could be done like this:

{
   locationOfSpeakers : sessions @map(key: "speaker.address.city") {
      speaker {
          address {
             city
         }
      }
    }
}

2. At the moment there is a difference between directives that can be used on lists and directives that can be used of list of objects. @uniq can be applied on a list of scalar values and returned a duplicate free list. @uniqBy(key: "foo") can be applied on a list of objects, and returns a list of objects that are distinct by the value of the field key
   At the moment we also have maxBy, minBy, meanBy, sumBy.
   To be consistent we would also have to create max, min, mean, sum.
   Alternatively we could combine these pairs of directives into one by making the key attribute optional.
   instead of

directive @uniqBy(key: String!) repeatable on QUERY | MUTATION | SUBSCRIPTION | FIELD
directive @uniq repeatable on QUERY | MUTATION | SUBSCRIPTION | FIELD

we could do

directive @uniq(byKey: String) repeatable on QUERY | MUTATION | SUBSCRIPTION | FIELD

3. Should we rename @drop and @dropRight to @skip and @skipRight. (as we also have @take and @takeRight)
4. Should we rename the Right part of @takeRight and @dropRight/@skipRight to End, Last or similar?

Product

Hot Chocolate

[michaelstaib]

@uniq and @uniqBy are misspelled.

Moreover, what is the count argument on the unique directive for.

Thirdly, we should have the by as an argument @unique(by: foo)

[michaelstaib]

I will do a more thorough review tonight.

[PascalSenn]

@uniq and @uniqby are misspelled.

Took this over from lodash, agree we should do @unique

Moreover, what is the count argument on the unique directive for.

This is indeed a bug of the documentation