Pagination concept

[raulk]

See: https://graphql.org/learn/pagination/

The edges->nodes indirection advised on that doc may be too heavyweight for us. A simpler aproach like making pageable entities implement a Pageable interface that adds an inner field cursor may be sufficient. See discussion below.

[pcardune]

One benefit of following that spec is that front-end graphql libraries integrate very nicely with it. See for example https://facebook.github.io/relay/docs/en/pagination-container.html

[raulk]

@pcardune thanks. That's an important factor I was missing. Are you guys at Nori planning to use Relay?

[pcardune]

Yes, we're already using Relay. Apollo client also supports relay-style pagination, though it appears to be less opinionated than relay: https://www.apollographql.com/docs/react/features/pagination.html#relay-cursors

[kshinn]

I've been thinking about this as well. From what I understand, the decision to support Relay is more than just a paging decision. It would require a schema overhaul to make it Relay compliant. I actually believe that the Connection model that Relay requires is a more common flavor of GraphQL in production (Facebook, Github, Shopify etc) and is more powerful in how it can represent information. However going that direction could pose problems getting adopted in an ecosystem that tends to favor simplicity. That being said, I think it would be a shame to not support a large part of the developer community that uses Relay.

With regards to the paging model, there are concepts that we could adopt from the Connection / Relay model that could be a start for moving that direction, but not necessarily overhauling the API out the gate. It does feel like there needs to be a bit more structure in the data returned than simply implementing an interface. I think to make paging off of a cursor model really useful, you would need a forward and backward direction starting from the cursor and some metadata around paging itself. Something like:

{
  pageInfo {
    startCursor
    endCursor
    hasNextPage
    hasPreviousPage
  }
  blocks [ Block ]
}

If you just embed the cursor directly into the block it would require iterating through the result set to find the start and end cursor. Additionally, there would be no indication that the client is on the last pageable set. With the current GraphQL schema, you would either need to introduce a new root object (such as pagedBlocks) or introduce a breaking change into the blocks object that would change the output format to something like the above mentioned shape.