3 ms·

I consider offset-based paged pagination to be a mark of the novice.

by MAGZine 4y ago

mcphage 4y ago
Or the mark of someone who asked the users what they wanted.
- MAGZine 4y ago
  I don't disagree, but everyone would prefer to have an API that worked over one that doesn't, or one that causes service outages due to database latency. (did anyone ask the users if they wanted the api to work?) If you're dealing with very small datasets, its fine. I'm an average person using average APIs, which means that when I see offset-based pagination, it's usually on a service deployed and used by a lot of people. Unsurprisingly, the offset based APIs often include some other arbitrary limit like "offset limited to 10k" or something silly but understandable if you've built an API used by thousands of people before, or understand how databases work. They're also often superseded by betters APIs that actually allow you to page the entire result set. Then you have a deprecated API that you either support forever or annoy users by turning it off. So yes, if you are building something non-internal/pet project, limit/offset is probably the mark of the novice.
steve_adams_86 4y ago
edit: I just saw another comment of yours, so I see this was meant more contextually than I realized. Can you explain why offsets would never be a suitable solution? Is there a clear explanation as to why? I understand how cursors are superior in some cases. But what if you have a site which paginates static data? Offsets would allow you to cache the results easily, overcoming any performance concerns (which would be irrelevant if the dataset was small anyway), providing a better user experience (and developer experience due to simpler implementation details) overall. I can see that it would be a novice move if you’ve got staggering amounts of records that take a while to query. But that’s actually pretty rare in my experience.
- MAGZine 4y ago
  It doesn't even have to be a cursor, you can technically page off of any field you can index (i've written a lot of sync APIs so there are gotchas, but the point stands). Limit/offset is usually (though not always, as you point out) egregious for anything more than hobbies or small projects. But, I am biased as when I build APIs, I definitely expect some amount of traffic/volume/tuple count, and offset/limit will not do.
  - steve_adams_86 4y ago
    Cool, I think we mostly agree. Thanks for the explanation!

I consider offset-based paged pagination to be a mark of the novice.

mcphage 4y ago

Or the mark of someone who asked the users what they wanted.

MAGZine 4y ago
I don't disagree, but everyone would prefer to have an API that worked over one that doesn't, or one that causes service outages due to database latency. (did anyone ask the users if they wanted the api to work?) If you're dealing with very small datasets, its fine. I'm an average person using average APIs, which means that when I see offset-based pagination, it's usually on a service deployed and used by a lot of people. Unsurprisingly, the offset based APIs often include some other arbitrary limit like "offset limited to 10k" or something silly but understandable if you've built an API used by thousands of people before, or understand how databases work. They're also often superseded by betters APIs that actually allow you to page the entire result set. Then you have a deprecated API that you either support forever or annoy users by turning it off. So yes, if you are building something non-internal/pet project, limit/offset is probably the mark of the novice.

steve_adams_86 4y ago

edit: I just saw another comment of yours, so I see this was meant more contextually than I realized. Can you explain why offsets would never be a suitable solution? Is there a clear explanation as to why? I understand how cursors are superior in some cases. But what if you have a site which paginates static data? Offsets would allow you to cache the results easily, overcoming any performance concerns (which would be irrelevant if the dataset was small anyway), providing a better user experience (and developer experience due to simpler implementation details) overall. I can see that it would be a novice move if you’ve got staggering amounts of records that take a while to query. But that’s actually pretty rare in my experience.

MAGZine 4y ago
It doesn't even have to be a cursor, you can technically page off of any field you can index (i've written a lot of sync APIs so there are gotchas, but the point stands). Limit/offset is usually (though not always, as you point out) egregious for anything more than hobbies or small projects. But, I am biased as when I build APIs, I definitely expect some amount of traffic/volume/tuple count, and offset/limit will not do.
- steve_adams_86 4y ago
  Cool, I think we mostly agree. Thanks for the explanation!