Пагинация это когда вы хотите, чтобы ваша ручка/сервис умела отдавать данные батчами по запросу. Плюсы такого подхода очевидны: вместо того, чтобы пытаться загрузить все данные разом (это долго и возможно не нужно), вы отдаёте только нужный кусок (ещё и уменьшая размер ответа).
Два основных подхода это использование offset и курсора.
Первый, это просто указание как много данных стоит пропустить от начала выдачи. После того, как вы получили первую 1000, можно запросить тот же запрос с offset=1000 и получить следующие 100 значений (чиселки условные конечно).
Оффсет может быть чуть более сложным, чем просто число (например номер страницы и номер последнего элемента на последней странице), но суть одна -- сдвиг от начала.
Проблема тут в том, что это может быть неэффективно. Например, если данные берутся из базы: вам необходимо сделать ваш [тяжёлый] запрос (мб с сортировкой и прочим) с чем-то вроде
OFFSET 1000 LIMIT 100, читай отбросить первую тысячу результатов (== выкинуть работу в мусорку) и взять следующую нужную пачку. Чем больше данных и чем меньше размер одного батча, тем больше работы мы делаем зря. Ещё данные приходится грузить в память (что не так плохо, когда у вас какой-нибудь новостной сайт без персонализации, но для чего-то более сложного не катит). И не оч работает, когда есть вставки/удаления. Не круто. Потому появился так же способ с помощью курсора. В базовом случае это может быть какой-то идентификатор (по сути индекс) строки в бд, которую можно получить быстро и выбрать после неё нужное количество данных. Удобно.
В более общем случае курсор может быть произвольного вида. Например для поисковой выдачи мы можем сделать курсор как множество метаданных для каждого дополнения нужного запроса:
[запрос: моло]
cursor: {
молоко: {
skip: 12,
min_relevant: 0.57,
},
молочное: {
skip: 27,
min_relevant: 0.13,
}
}ну или рандомный хеш данных, которые были получены последними вроде ASdlakBLADSoPVDOUA🚬
В целом вместо явного курсора так же можно генерить ссылку на следующую пачку данных.
Тут сложнее узнавать кол-во данных, но ниже вероятность их потерять (кроме случаев, когда запись, на которой основан курсор, удалили).
Детектить конец пагинации можно разными простыми способами: дополнительное поле, присылать null значение для курсора или повторять его.
Вообще конечно пагинация не цель, а метод решения бизнесовых задач, потому если в силу каких-то ограничений нельзя сделать честную рабочую пагинацию, можно попробовать зайти с другой стороны. Например, делать несколько запросов с клиента разных размеров, чтобы первым маленьким быстро дать первую пачку результатов, и конкурентно сделать большой запрос, который выполнится чуть дольше, но вернёт сильно больше данных (пофильтровав руками дубликаты). Если надо, повторить аналогичное ещё несколько раз с увеличением размера запроса. Т.е. конечно накостылить, но проблему решить.
Links:
1. Five ways to paginate in Postgres, from basic to exotic.
2. How to Implement Cursor Pagination Like a Pro.
3. Paginating Real-Time Data with Cursor Based Pagination.
======================
Блин вас уже полтысячи. Неожиданно и приятно. Всем спасибо.