4 ms·
I think is better to not use pagination at all. Design your api or page so that you receive all or more entries than you could possibly need. If the user want
by callesgg 6y ago
I think is better to not use pagination at all.
Design your api or page so that you receive all or more entries than you could possibly need.
If the user wants them all pagination is just in the way.
If the user does not want them all give them as many as they are likely to be able to handle.
- hellcow 6y ago"Woah, our database is slowing to a crawl, requests are deadlocked everywhere. Yeah, some asshole is hitting GET /messages and pulling 2TB in a single request again." "Surely that's what he wanted."
- callesgg 6y agoGiven that is what the person is doing, that is likly what they are trying to do. Most of the times when I do things, I do it cause I want to do it, not cause I did an opsie.
- scrollaway 6y ago"let's allow users to DOS us in a single request if they want to" is not an acceptable design decision, I'm sure you are aware of that.
- callesgg 6y agoMost services don’t handle ddos amounts of data, a few 1000 rows of data is fine. Don’t design like you are Twitter if you are not. It is a waste of man hours. If I as a client need 10 000 rows of data that is what I will ask for either in one request or in a 100 consecutive.
- Can_Not 6y agoThis is terrible advice, sending the client as little as reasonably possible (therefore use pagination) is the most sane, performant, affordable, and secure default assumption. Any rails/laravel/feathersjs style framework have multiple types of pagination built in for free.
- callesgg 6y agoPerformant for you assuming the client gives up after the first page. Less performant for you and the world as a hole if the client actually needs the data it ask for. Cause if it needs it the client will just make the request 100 times until it has all the data. What is more performant one query or a hundred.