You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 21, 2022. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 aPageable
interface that adds an inner fieldcursor
may be sufficient. See discussion below.The text was updated successfully, but these errors were encountered: