–– [TASK] Рефактор/добавление пагинации для query эндпоинтов

[ronimizy]

Goal

Добавить поддержку пагинации для query эндпоинтов (пользователи, группы, студенты)

Motivation

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

Implementation

• разработать механизм получения одной страницы между несколькими сервисами
• убрать возврат количества страниц для существующей пагинации
• переработать sdk

[ronimizy]

Текущий стейт

Есть следующие query эндпоинты:

• Student (StudentController.Query)
• UserIdentityInfo (UserController.GetUserIdentityInfosAsync)
• StudyGroup (StudyGroupController.Query)

Пагинация уже есть на UserIdentityInfo, но выполнена следующим образом:

• получается по номеру страницы
• отдаётся общее количество страниц

Почему тут вообще есть проблема?

В Student и UserIdentityInfo, одним из критериев фильтрации является Github username, так как гитхаб был вынесен в отдельный модуль, у нас получается двухфазная фильтрация, сначала идём в core бд, делая фильтрацию по всем остальным признакам, далее идём в GitHub сервис, получаем данные по айдишникам, объединяем их и фильтруем.

Проблемы в еализации с UserIdentityInfo

Тут проблема заключается в том, что у нас не получится узнать общее количество страниц, не выгружая из бд список айдишников всех пользователей (подходящих под запрос), и не выгружая у GitHub сервиса данные по всем этим пользователям. Это приводит к тому, что мы читаем очень много данных чисто ради того, чтобы отобразить пользователю красивые циферки, которые в целом не особо нужны (если юзер ищет что-то конкретное, то дополнит фильтр, если нет, то энивей будет идти по страницам по порядку)
Плюс, когда я эту пагинацию писал, я не особо об этом моменте подумал, так что при использовании гитхаб фильтра выдаётся неверное количество страниц.

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

Проблемы в желаемой реализации

Поскольку фильтрация двухфазная, перед нами встаёт проблема того, что нам нужно обеспечить соответствие количества отданных данных заданному в конфигурации размеру страницы, во всех случаях, кроме того, когда мы с данного курсора получили пользователей из базы – меньше чем размер страницы (последняя страница)
Реализовать такое можно повтором операции получения пользователей из базы по query + фильтрация по GitHub, пока либо, их количество не будет равно размеру страницы, либо, из базы будет получено 0 записей (т.е. последняя страница)
Так же в результате нужно передавать курсор, с помощью которого можно будет подгрузить следующую страницу, или null, отданная страница – последняя.
Тут по идее стоит запрашивать PageSize + 1 записей, чтобы обеспечить валидность курсора для продолжения, чтобы когда Entities.Count % PageSize == 0, мы верно определяли, что данная страница – последняя, и фронту не пришлось лишний раз ходить на бек за пустой страницей.