You don't want to repeat these fetches in the followup queries, they're redundant, and assuming the API is rate-limited they will decrease your query budget for no value.

That counts double if you're fetching multiple paginated fields (which also adds to the awkwardness).

Your pagination is now two-dimensional, with each node's start/limit as points on its own axis.

Now add a third node to the query. Now you have three-dimensional pagination. This quickly goes off the rails.

Try writing a generic N-dimensional paginator for such a query to see why it's difficult. Even designing a sensible and reasonably flexible API for one is a headache.

TBF you could also deal with it using fragments I think, but still, not great.

Most of the simple ways of doing it with SQL are problematic. In these docs

https://docs.spring.io/spring-batch/docs/current/reference/h...

there is some discussion of the problems and some answers that go back to the mainframe era.

But very often, a result missing or duplicated in a few queries isn't a showstopper. On that case, pagination is very simple.

That is you are "full scanning" and making a report or doing something like a reconciliation process in a financial institution, it is not like some image boards where there is a link to the 1781th page of images but it spends forever loading it if you click on it.