Pagination

Our support for pagination relies on exposing connections in a standardized way. In the query, the connection model provides a standard mechanism for slicing and paginating the result set. In the response, the connection model provides a standard way of providing cursors, and a way of telling the client when more results are available.

Taking the example of the following query:

{
  partner {
    id
    chats(first: 10, after: "opaqueCursor") {
      edges {
        cursor
        node {
          id
          question
        }
      }
      pageInfo {
        hasNextPage
      }
    }
  }
}

In this case, chats is a connection. This query demonstrates the four features described above:

• Slicing is done with the first argument to chats. This asks for the connection to return 10 chats.
• Pagination is done with the after argument to chats. We passed in a cursor, so we asked for the server to return chats after that cursor.
• For each edge in the connection, we asked for a cursor. This cursor is an opaque string, and it is precisely what we would pass to the after arg to paginate starting after this edge.
• We asked for hasNextPage; that will tell us if there are more edges available, or if we’ve reached the end of this connection.

Pagination algorithm

The default value for first is 10. Any value between 1 and 100 is valid. It controls the number of objects returned per request. If none is given, the default will be used.

1. Invoke the connection returning query, e.g. chats, passing the page size as the first argument.
2. For each edge process the associated node that will contain the fields requested, e.g., question and save the cursor of the last processed edge.
3. While hasNextPage is not false, invoke the connection, e.g., chats, passing the page size as first and the cursor of the last processed edge as after and go to 2.