How to handle forward and backward pagination properly with GraphQL

[albx]

Hi everyone.
I'm using Data API Builder to create a GraphQL endpoint and I noticed that the schema for a connection has an endCursor property, which indicates the cursor to use for moving forward in the pagination.

However, I'm not sure how to handle backward pagination, because it seems that the schema does not provide any information to move to a previous page.

As far as I know, HotChocolate supports two approaches:

• with cursors, it shows both an endCursor and a startCursor (see https://chillicream.com/docs/hotchocolate/v13/fetching-data/pagination#connections)
• with offset, using skip and take properties (see https://chillicream.com/docs/hotchocolate/v13/fetching-data/pagination/#offset-pagination)

Relay, on the other hand, uses a cursor approach but it allows both forward and backward pagination using an after and a before property, which contain the cursor value (see https://relay.dev/graphql/connections.htm#sec-Forward-pagination-arguments and https://relay.dev/graphql/connections.htm#sec-Backward-pagination-arguments).

Is there is any way to achieve this? Please, let me know if you need more informations.
Thank you very much!

[frekvent-szabolcs]

Ran into this as well. If you are using a SQL database, you can define a stored procedure that queries the meta data needed for your pagination.

The endCursor is a base64 encoded string. If you decode it, you get something like this:

[{"EntityName":"Currency","FieldName":"Code","FieldValue":"RSD","Direction":1}]

The direction needs to match your current sorting and the field value specifies after which value you want the page.

So If you have a sp that takes the PageSize as a parameter and returns something like this (ex PageSize=2):

PageNum	IsFirstInPage	IsLastInPage	Code
1	1	0	EUR
1	0	1	GBP
2	1	0	HUF
2	0	1	RON
3	1	0	RSD
3	0	1	USD

You can compose the endCursor object yourself and encode it as a base64 string.

You can call the SP using graphql:

This only works for a fix sorting parameter. You can add a second parameter to the stored procedure and use ORDER BY CASE WHEN @SortField = 'Column1' ELSE ... to figure out the pages.

Another thing to consider: If the pagination meta data is too large, you probably need infinite scrolling anyway or If you only want forward and backward buttons, you can store the field values needed inside the client's state (every time you page, you store the previous last page item value).

[albx]

Thanks for the reply.
Yes, in the end I stored the cursor in memory, enabling only forward and backward buttons (see https://live.morialberto.it/archivio as a sample (italian language)).

Interesting the Stored procedure, I didn't know the form of the cursor in such a deep way :).

[Baker-Denn]

I solved this by creating a Dictionary<int,string?> that stored the cursors as the user paged the results:

# Sets defaults values
private int currentPage = 1;
private Dictionary<int, string?> pageCursors = new() { { 1, null } };

# Increments current page and adds cursor to dictionary
private void NextPage(string cursor) => pageCursors[++currentPage] = cursor;

# Decrements current page
private void PreviousPage() => currentPage--;

Then I simply pass pageCursors[currentPage] as my after value to my query.

[albx]

Yep, I did the same thing 😄 (https://github.com/albx/live.morialberto.it/blob/main/src/MoriAlberto.Live.WebSite/Services/PageCursorProvider.cs)