Add aggregate function support

[qexpres]

Right now it is impossible to perform precalculations for aggregate functions on the graphql service. For a simple use case, such as counting linked relations, you have to query the items with their links and then you locally compute whatever you want to know (e.g. count, sum, average).

This is fine, as long as the lists aren't too big, but in my case the lists do become too big. This results in websocket frames being larger than 3MB and it takes quite some time to load. The biggest problem is not being able to count list sizes server-side.

Now, if I want to show the book count for each author, I need to query for the linked books and calculate each list size:

subscription {
  authors {
    id
    name
    books {
      id
    }
  }
}

Imagine getting 20 authors with 1000 to 8000 books each, and then you see my problem; the server gives an author list with book lists of the form books: [{id: 1, __typename: "Book"}, {id: 2, __typename: "Book"}, ...] while I'm only interested in the total book count.

My proposal is the following addition to graphql service's functionality:

subscription {
  authors {
    id
    name
    books@count
    books@avg(field: "sold")
  }
}

This would then return:

{
  "data": {
    authors: [
      {
        "id": 1,
        "name": "Jasper",
        "books@count": 1322,
        "books@avg": 341.5,
      }
    ]
  }
}

I am not entirely sure whether this is valid graphql, but I think this is the most intuitive syntax, keeping on mind realmjs' query language. For now I really need the aggregate count, but I also added @avg to show how aggregate functions would fit this syntax if they need additional parameters, such as calculating the average of a field.

[rolfdalhaug]

+1 asap please

[qexpres]

Any thoughts on this? I'd be happy to figure something out by myself, but I would really love your support. In particular if we could agree upon a syntax.

[nirinchev]

One compelling aspect of the current design is that we don't do anything custom about resolving object properties. Since they are already present on the Realm object, we just pass it to Apollo and it looks them up based on what the user has requested. Obviously, we can change that, but it requires a bit more effort around forming the response, which is why we haven't had time to look into this.