5 ms·

As a user I expect that to happen. Cursors on the other hand are awful for getting to arbitrary pages, they are mostly useful for "More" links as on HN or Reddi

by kaoD 6y ago

As a user I expect that to happen. Cursors on the other hand are awful for getting to arbitrary pages, they are mostly useful for "More" links as on HN or Reddit. It's a trade-off.

felixfbecker 6y ago
Cursors are also the only reliable option for supporting programatic usage for automation use cases.
masklinn 6y ago
I’d say they’re right: cursors are way better for an API. Pages are way better for a person. This here is about an API.
- matt-attack 6y ago
  Well good luck giving your users direct page access when your API only supports cursors.
- tstrimple 6y ago
  How often do people really jump to an arbitrary page? I'd say filtering / searching capabilities are far more important for users than paging.
  - _nothing 6y ago
    It depends? If I'm looking for a new desk on IKEA's online catalog then I care more about filtering/searching, but if I'm reading through a conversation on a forum and want to be able to link to certain sections then I want that paginated.
    - tshaddox 6y ago
      But even for the latter case, surely you're not specifically interested in a specific page called "page 50" but rather you're interested in items satisfying some predicate (like "posts from 2 weeks ago") or locations respective to the entire list (like "halfway through the list"), and it would be much better if the user interface supported those sorts of navigation.
- gls2ro 6y ago
  Here I think it makes sense to split the API in two classes: 1. APIs consumed by other backends lets call them API2B 2. APIs consumed by frontends lets call them API2C In this case cursors are better for API2B but not for API2C as in case of API2C most users expect to be able to jump directly to a specific page. At least when I am designing an API i take different decisions based on this split. For example in case of API2C I always want to see FE design even if I work on backend.
tshaddox 6y ago
The notion of "page" really only applies as an arbitrary interface division to make performance predictable. The same book could be published in different form factors such that there's no real meaning to a specific page number. There's no "turn your bibles to page 112." That's even more clearly true when the data itself is changing over time, such that even the first thing on the first page is changing over time. Thus using page numbers is probably a pretty poor proxy for what you're actually trying to do when you say "getting to arbitrary pages." Presumably you are wanting to skip to a specific place in the list, perhaps specified as a percentage ("take me halfway through the list") or as some predicate on the data ("take me to items from 2 weeks ago"). APIs should provide ways of expressing these specific places in a list, instead of requiring you to either guess page numbers or do extra work to calculate them.
- 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 ago
    There 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.)

by kaoD 6y ago

As a user I expect that to happen. Cursors on the other hand are awful for getting to arbitrary pages, they are mostly useful for "More" links as on HN or Reddit. It's a trade-off.

felixfbecker 6y ago

Cursors are also the only reliable option for supporting programatic usage for automation use cases.

masklinn 6y ago

I’d say they’re right: cursors are way better for an API. Pages are way better for a person. This here is about an API.

matt-attack 6y ago
Well good luck giving your users direct page access when your API only supports cursors.
tstrimple 6y ago
How often do people really jump to an arbitrary page? I'd say filtering / searching capabilities are far more important for users than paging.
- _nothing 6y ago
  It depends? If I'm looking for a new desk on IKEA's online catalog then I care more about filtering/searching, but if I'm reading through a conversation on a forum and want to be able to link to certain sections then I want that paginated.
  - tshaddox 6y ago
    But even for the latter case, surely you're not specifically interested in a specific page called "page 50" but rather you're interested in items satisfying some predicate (like "posts from 2 weeks ago") or locations respective to the entire list (like "halfway through the list"), and it would be much better if the user interface supported those sorts of navigation.
gls2ro 6y ago
Here I think it makes sense to split the API in two classes: 1. APIs consumed by other backends lets call them API2B 2. APIs consumed by frontends lets call them API2C In this case cursors are better for API2B but not for API2C as in case of API2C most users expect to be able to jump directly to a specific page. At least when I am designing an API i take different decisions based on this split. For example in case of API2C I always want to see FE design even if I work on backend.

tshaddox 6y ago

The notion of "page" really only applies as an arbitrary interface division to make performance predictable. The same book could be published in different form factors such that there's no real meaning to a specific page number. There's no "turn your bibles to page 112." That's even more clearly true when the data itself is changing over time, such that even the first thing on the first page is changing over time. Thus using page numbers is probably a pretty poor proxy for what you're actually trying to do when you say "getting to arbitrary pages." Presumably you are wanting to skip to a specific place in the list, perhaps specified as a percentage ("take me halfway through the list") or as some predicate on the data ("take me to items from 2 weeks ago"). APIs should provide ways of expressing these specific places in a list, instead of requiring you to either guess page numbers or do extra work to calculate them.

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 ago
  There 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.)