Comments 16
Не хватает фото пушистиков для наглядности.
В "OpenAPI и JSON-Schema вы можете в моей статье на Хабре." Ссылка никуда не ведёт.
Как пагинация совмещается с фильтрацией? Можно расширить текст на случай наличия простого фильтра.
Тема пагинации не раскрыта. Как фронтенд узнает, сколько кнопочек вперёд-назад рисовать?
Достаточно сделать по одной кнопочке вперёд-назад, на крайний случай третью - двойное вперед >> (к самой последней записи).
Запрашивать из БД общее количество записей и затем делить на количество записей на страницу для подсчёта количество страниц - не самое оптимальное решение, потому что SELECT COUNT(*) это одна из самых «тяжелых» операций.
SELECT COUNT(*) это одна из самых «тяжелых» операций
а есть какие-то объективные данные на сей счёт? не из головы, а чтобы на замеры посмотреть? это одна из самых тривиальных операций для любой СУБД.
ответьте на такой вопрос. как интерфейс сообщит пользователю, что кликать по кнопке "вперёд" не имеет смысла (т.е. она должна быть как минимум деактивирована) в случае, если мы достигли последней "страницы" в базе согласно лимиту и оффсету и клик по следующей заведомо приведет к пустому ответу БД потому что записей с такими лимитом и оффсетом в базе попросту нет?
По вопросу возвращения количества записей в ответе согласен, я изначально ввел всех в заблуждение, т.к. рассказывал про получение записей на UI, а в голове держал взаимодействие back2back, когда нет смысла передавать этот параметр.
Чтобы не городить костыли, действительно целесообразно получать в ответе totalCount. Но если записей слишком много, то смысла пользоваться offset-пагинацией нет, и целесообразнее перейти к реализации с помощью, например, keyset-пагинации.
Спасибо, что внимательно прочитали и обратили внимание, статью отредактировал.
Похоже пост ради ссылки на канал. Оно в целом не очень плохо, но технический уровень очень плох. Тема конечно простая и даже помечено мол тут всё просто. Но по факту и сам вариант решения имеет проблемы.
Вообще, по хорошему, нужно всегда отдавать объект. По простой причине - очень частно нужны метаданные. Для той же пагинации хорошо бы знать сколько элементов вообще есть в списке всего. Обычно отправляется объект, в нем есть ключ items или подобное, там массив самих данных. Рядом едет ключ pagination, внутри объект с данными пагинации - как минимум ключ total где показывается сколько данных всего. Это важно - как минимум знать какая страница последняя и понимать что кнопку «далее» рисовать не нужно. А в идеале ещё и выводить мол нашлось столько то, где-нибудь внизу таблицы. Также помимо пагинации иногда нужно отправлять ещё какие-нибудь данные и вот с объектом всё выходит прекрасно.
По именованию recordsPerPage вопросы, почему так длинно. Хотя иногда бывает, но можно взять что-то классическое вроде skip и limit. Ну ли page и pageSize. Многословно выходит.
Также не раскрыта тема ленточной пагинации. При интенсивном потоке данных имеет смысл в пагинации по lastId и подобному.
Спасибо за подробный комментарий и, что как и пользователь выше, обратили внимание на необходимость наличия ключа total для корректной отрисовки UI, отредактировал статью.
Про ленточную пагинацию изначально не планировал писать в статье, но сейчас привел краткий пример.
Тот прекрасный случай, когда камменты рулят. Спасибо! Люблю за это Хабр
Предположим, на момент просмотра 1-й страницы в базе имеется 100 записей с id от 1 до 100.
Выводим записи с обратной сортировкой по id, 10 на страницу. В этом случае на первой странице отобразятся записи с 100 по 91 включительно.
Пока менеджер просматривал страницу, в базу добавилось ещё 3 записи с id 101, 102, 103.
Менеджер нажимает кнопку перехода на следующую страницу и... ему отобразится что?
Записи с 90 по 81 включительно? Или с 93 по 84? Так он же уже их просматривал? А если записи добавляются быстрее, чем менеджер просматривает (а в Вашем примере со 100 операторами это вполне реально).
Ну и вишенкой на торте: а на кой чёрт здесь вообще аналитик? Бюджеты пилить? Разработать API должен уметь любой мидл, не говоря уже о сеньоре (как по мне, разработчик, не умеющий в такие вещи, вообще профнепригоден, но я уже привык, что джуны сейчас слегка умнее шимпанзе).
Менеджер нажимает кнопку перехода на следующую страницу и... ему отобразится что?
Вы абсолютно правы, в моем примере я и указал, что offset-based пагинация может приводить к неконсистентности часто обновляемых данных и лучше использовать курсоры, так как они вернут результаты, существующие в базе на момент начала транзакции.
Целью статьи вообще было показать, как можно спроектировать простой API-метод, описав его с помощью двух разных подходов, не углубляясь в тонкости реализации логики на бэке или фронте, так как в начале материала я даже отметил, что он ориентирован на начинающих аналитиков.
Ну и вишенкой на торте: а на кой чёрт здесь вообще аналитик?
Последние лет пять большом энтерпрайзе (во всяком случае там, где работал я и где работали мои знакомые) переходят к api first. В связи с этим - огромный спрос на аналитиков, и одна из их задач - это отдать готовую спецификацию разработчику, чтобы тот не тратил своё время на написание и поддержание документации. Бюджет хоть и расходуется, но time to market продукта получает неплохой прирост.
Косвенно, это подтверждается огромнейшим спросом на рынке РФ (возьмите хотя бы hh - там количество вакансий SA уже второе по количеству после разработчиков).
Спасибо большое за статью!
Я пока только начинающий СА, всплыла пагинация и нужно было найти хорошую статью по этой теме. Ваша статья однозначно хорошая! Очень приятный слог и понятное изложение. Пожалуйста, пишите ещё <3
Реализация REST API-метода с пагинацией на примере JSON-Schema и OpenAPI