Какие данные нужно передавать бэкенду для пагинации и почему?

Пагинация нужна, чтобы клиент получал данные порциями, а не весь список сразу. Если бэкенд отдаёт миллион записей одним ответом, это перегружает сеть, память сервера и клиента, а также замедляет рендеринг. Поэтому клиент сообщает серверу, какую часть данных он хочет получить.

Основные параметры

• page и limit — номер страницы и количество элементов на странице. Простой и понятный вариант для UI.
• offset и limit — сколько записей пропустить и сколько вернуть. Часто используется на уровне SQL.
• sort — поле и направление сортировки. Без стабильной сортировки страницы могут дублироваться или терять записи.
• filters — условия выборки, чтобы пагинация работала по нужному подмножеству данных.
• cursor — идентификатор последней записи для cursor-based пагинации. Устойчив к вставкам и удалениям.

Пример на Node.js и SQL

// GET /users?page=2&limit=20&sort=created_at:desc
app.get('/users', async (req, res) => {
  const page = Number(req.query.page) || 1;
  const limit = Math.min(Number(req.query.limit) || 20, 100);
  const offset = (page - 1) * limit;

  const users = await db.query(
    'SELECT * FROM users ORDER BY created_at DESC LIMIT $1 OFFSET $2',
    [limit, offset]
  );

  res.json({ page, limit, data: users.rows });
});

Offset против cursor

Offset-пагинация проста, но на больших offset база вынуждена пропускать много строк, что замедляет запрос. Кроме того, если данные меняются между запросами, элементы могут дублироваться или исчезать. Cursor-пагинация использует значение последней записи (например, id или created_at) и работает стабильнее и быстрее на больших объёмах.

// GET /users?cursor=12345&limit=20
SELECT * FROM users
WHERE id < $1
ORDER BY id DESC
LIMIT $2;

Итог: для простых админок и небольших списков достаточно page/limit или offset/limit. Для лент, чатов и больших таблиц с частыми изменениями лучше применять cursor-based пагинацию, чтобы сохранить производительность и консистентность данных.