Token on the next page in the pagination API

Question

I have a list of records on the server, sorted by key, and use the pagination API to return a list of segments one by one. Since items can be inserted in the middle of the list, I return the first key of the next page as the page token that must be transferred to get the next page.

However, I found that DynamoDB uses the last key of the current page instead of an API request, which is null if the next page does not exist.

Question:

What are the pros and cons between using the last element of the current page and the first element of the next page as the pagination token?

NB:

As for me, returning the first element is more intuitive, since it is null only if the next page does not exist.

Answer 1

Using the "last element of the current page" ( LICP ) is better than using the "first element of the next page" ( FINP ), because it works better with the possibility that some element is inserted between these two elements.

For example, suppose the first page contains 3 alphabetically ordered names: Adam / Basil / Claude. And suppose the next page is Elon / Francis / Gilbert.

Then with the LICP token Claude , and with the FINP token Elon . If new names are not inserted, the result is the same when we get the next page.

However, suppose we insert the name Daniel after getting the first page, but before getting the second page. In this case, when we get the second page with LICP, we get Daniel/Elon/Francis , and with FINP we get Elon/Francis/Gilbert . That is, FINP will skip Daniel , while LICP will not.

In addition, FINP can consume more computational resources than LICP, since you should get one additional element (4 elements in the above example, not just 3).