2 ms·
Isn't that just pagination with a different granularity? You'd still present the user with a set of results (a "page") and would let them seek forwards/backwar
by kaoD 6y ago
Isn't that just pagination with a different granularity?
You'd still present the user with a set of results (a "page") and would let them seek forwards/backwards to the adjacent subsets of results.
AFAICT cursors can't support this.
And even if you go halfways into the list you can't display all subsequent items, so you'd still have to paginate in some way.
The page metaphor is there for a good reason.
- tshaddox 6y agoThere are two concepts here. One is simply the idea of a service returning only some portion of the items in a list for each request. That notion almost always exists simply for practical reasons: to bound the performance for retrieving, formatting, transferring, and consuming the list. I have no problem with that. The other concept is using an actual page number to make requests, e.g. requesting {page: 1} and then subsequently requesting {page: 2}. This concept is the one I was claiming is less desirable than some alternatives. As for cursors, I don't see any reason why you couldn't make requests like {listPosition: "50%"} or {createdBefore: "2020-02-15"} and then still use cursors in the response to request the previous or next page. (Those two examples probably aren't actually good API naming conventions, but it should demonstrate the idea.)