Lighthouse: Change default pagination argument from `count` to `first` and add more pagination args

[e200]

What I'm suggesting is to rename the @pagination directive argument count to first since it makes more sense. Count stands more for an operation than a filter argument.

I want also suggest to add more pagination arguments, like last:

query RECENT_PRODUCTS {
  products(last: 15) {
    data {
      name
    }
  }
}

[lucasmichot]

I guess ppl are missing many other args too
Working now on a PR that gives more flexibility

[spawnia]

Can you give an usage example for the extra args you are referring too?

[lucasmichot]

before and last for instance

# Github
{
  repository(owner: "nuwave", name: "lighthouse") {
    issues(last: 20, before: "Y3Vyc29yOnYyOpHOGMtGew==") {
      nodes {
        id
        title
        createdAt
      }
    }
  }
}

[e200]

query RECENT_PRODUCTS {
  products(last: 15) {
    data {
      name
    }
  }
}

[spawnia]

I am not sure i love first in combination with page.

The examples for last and before make sense to me, seems like something we might do.
How would that actually look like in terms of implementation? It seems especially tricky to do with cursor-based pagination.

[e200]

If the last argument makes sense, then the first makes too. Definitely use limit or first makes more sense then count.

users (count: 10) {
  name
}
users (first: 10) {
  name
}

The user must be smart enough to understand that page is more related to pagination while first will work using @paginate or not.

[lucasmichot]

Actually if we take the example of Github GraphQL implementation, there is no page.
There will always be first, last, before and after + extra parameters depending on the connection type.

An error message is also returned when using first and last toegether:

{
  "data": {
    "repository": null
  },
  "errors": [
    {
      "path": [
        "repository",
        "issues"
      ],
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "message": "Passing both `first` and `last` to paginate the `issues` connection is not supported."
    }
  ]
}

[spawnia]

@chrissm79 are you fine with changing count to first?

[chrissm79]

I would like to stay away from forcing a breaking schema change on users if it's avoidable. I would purpose that we create an interface that (1) returns the input type and (2) handles manipulating the query. This will also allow for users to define their own pagination structure while leveraging Lighthouse to optimize the rest of the query. Just so long as the default doesn't cause a breaking schema change I be happy to accept a PR on it!

[e200]

Since we're talking about GraphQL, you can implement both and mark count as deprecated?

[spawnia]

@e200 seems like a good way of moving this forward.

Ultimately, i think the consistency of having both pagination styles work similar is going to be worth it.

[e200]

Any plans to implement that @spawnia?