Какой API лучше всего сделать для получения динамического списка по частям?

Question

[Александр Интересный]

Добрый день. Моя задача — создать динамический список пользователей, то есть добавить, удалить или изменить статус нового пользователя в любое время. На бэкэнде он сортируется по последней активности. Имеется ввиду, что недавно активные пользователи находятся вверху, а давно активные — внизу. На фронтенде у меня есть список, загружаемый с помощью слайсов (get_members # limit 20, offset 20) делая infinite-scroll. Но, если добавляется новый пользователь, логично, что он появится вверху списка, тогда как в моем случае первая часть списка уже загружена и кэширована. Соответственно, до добавления нового пользователя последний пользователь в моем списке имел ID 20, а на следующей странице список начинается с ID 21. Но когда добавляется новый пользователь, следующая страница возвращает ID 20 из-за смещения.

Если я просто проигнорирую существующий список и сразу добавлю 20 новых пользователей, следующая страница будет буквально заполнена дубликатами, и ничего не загрузится. Как правильно спроектировать систему страниц, в которой уже загруженные страницы также могут изменяться? Я планирую хранить на фронтенде только три страницы: предыдущую, отображаемую и следующую. Также я хочу иметь возможность прокрутки вперед, например, на 20 страниц. Я представляю себе следующий сценарий: на бэкенде есть текущий отсортированный список пользователей, а фронтенд получает слайсы этого списка. У меня есть два варианта: либо заменить все локальные (фронтенд) страницы новыми пользователями и попытаться каким-то образом сохранить положение прокрутки списка, либо динамически вставлять каждую страницу и вернуться к исходной проблеме дубликатов и нестабильности. Или есть лучшие варианты? Буду благодарен за любые идеи и предложения.
Также хочу учесть, что я использую веб-сокет, а не REST API. Теоретически я мог бы поддерживать обновление текущей страницы на стороне клиента. Например, я мог бы создать события для добавления, удаления и изменения статуса конкретного пользователя. Но это теоретически может привести к проблемам с сетью и рассинхронизации

Comments

[Алексей Уколов]

Вам нужна курсорная пагинация по времени последней активности (и я бы дополнительно ещё добавил id для коллизий времени).

[Александр Интересный]

Алексей Уколов, а есть какие то примеры? у меня для сообщений используется как раз курсорные запросы, но я все таки не понимаю, как реализовать такую систему в моем случае, с ограничением в например 20 пользователей на запрос. то есть я во время построения ответа на бекенде создаю список с нуля, но он будет кардинально отличаться от списка не фронтенде и мне надо максимально оптимизированно, быстро и без перезагрузок синхронизировать.

Вот такие у меня классы на получение сообщений:

@FrontendGeneration
    public enum ListDirection {
        latest,
        next,
        prev
    }

    @FrontendGeneration
    public static class ListQuery extends GeneralClasses.SlClass {
        @FieldNullable
        public String pointer;
        public ListDirection direction;
    }

Answer 1

[rPman]

идеологически постраничная навигация это глючное наследие прошлого, когда про UI не думали, на одну из проблем вы наступили.

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

В итоге в интерфейсе у вас не будет кнопок перейти к N-ой странице, а будет перейти к следующей, к предыдущей и последней (можно добавить по шагам). Тут же можно сделать ссылки по какому то критерию, который нужен пользователю, например по тому по которому проходит сортировка.

Подумайте очень хорошо, зачем пользователю нужно видеть ВСЕХ записи постранично, да еще и с мониторингом изменений в реальном времени

Comments

[Александр Интересный]

В целом звучит хорошо. Но хочу подчеркнуть, что я делаю сервис мгновенного обмена сообщений и у меня список пользователей сообщества. Там список должен постоянно обновляться, так как пользователь вошел в сеть - сразу появился вверху. При этом поддерживать infinite-scroll (авто подгрузка следующей страницы при скроле ниже), при этом отгружать предыдущие страницы вне зоны видимости. С помощью виртуализации списков это сделать гораздо проще, но тем не менее, как правильно построить API

[rPman]

именно такой алгоритм и подойдет

при просмотре топа, отображать обычный 'select ... order by ... limit ...'
а при постраничной навигации отображать '10 записей после указанного id'

p.s. про api, ты запрашиваешь у сервера страницу с мониторингом изменений, не важно как ты запросил сами данные, работающий рядом websocket будет принимать updates от сервера (самый тупой алгоритм - приходит приглашение на обновление страницы, чуть более продвинутые сразу в этом же канале данных присылают измененную страницу, ну и самый 'крутой' может прислать только diff, это вопрос что дороже, сеть или процессор на сервере)

[fgengine]

По страничная загрузка Offset-Limit/Page-Size
В классическом виде хорошо работаю только на редко обновляемых данных.

Но можно использовать примерно следующие манипуляции

Чтобы исключить проблемы потерянных пользователей

1 - Надо загрузить в страничном варианте с сортировкой где новый пользователь будет либо в начале списка либо в конце (например по дате присоединения к списку друзей). Минимальные данные которые потребуются для загрузки ID, и набор дат (например дата изменения профиля, дата последнего сообщения и тд). Запустить серию запросов по загрузки самих данных. Обязательно сохранить в локальную БД или кеш.

2 - Слушать WebSocket канал (или периодический дергать REST) в который будет уведомлять о том что пользователи совершают какие либо действия (важно не получать сами данные, а регистрировать какие данные были изменены), дальше запускать серию запросов по загрузки самих данных (например добавился новый друг и нужно загрузить его профиль, написали в чат и тд), после синхронизации обновлять UI.

3 - Выводить список пользователей из БД с нужной для приложения сортировкой.

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

Используя что то похожее можно получить следующие
Плюсы:
1 - Данные не будут загружаться только если приложение их ранее не загружало (либо когда приложение удалило слишком старые данные но пользователь захотел их заново просмотреть)
2 - Возможность просмотреть чаты при плохом интернете
3 - Можно совмещать WebSocket + REST

Минусы:
1 - Сложность разработки и сопровождений серверной части (ведение журнала активности)
2 - Сложность разработки и сопровождений клиентской части (синхронизация локальной БД в соответствии с журналом)

Answer 2

[Станислав Сударев]

Привет! Я попробую описать свое видение, если покажется подходящим, но не совсем понятный, дай знать, я ещё распишу:)

В твоем кейсе можно попробовать делать запрос в бекенд по датам последней активности.

В твоем кейсе изменение можно прийти только "сверху", и не будет изменения внутри страницы (потому что время всегда идет вперед)

Когда ты получаешь первую страницу, можно сохранить временные границы этой страницы (onlineDate1 и onlineDate2).

Далее при пролистывании вниз, идет запрос с onlineDate2. На беке делается фильтр по этой дате и берется (take) 20 элементов.

После можно сохранить для страницы новый границы.

Итого у тебя три отрезка времени, для верхней, текущей и следующей страницы

Когда придут новые динамические изменения можно проверить:
Если твоя верхняя страница имеет меньше 20 элементов(другими словами если пользователь не отлистал дальше первой страницы), то можно вставить сверху "верхней" страницы (после этого обновить "границы" верхней страницы)

Если элементов верхней страницы уже 20 , значит можно не вставлять. Потому что пользователь этого уже не увидит. А когда пользователь начнет листать вверх, то можно сделать запрос на бек onlineDate1 для верхней страницы. На беке будет фильтр onlineDate < onlineDate1, потом сортировка onlineDate desc и потом take 20.

Так ты получишь следующую верхнюю страницу.

Листанре вниз проще, там просто по onlineDate2 вниз фильтруешь. Потому что динамически там не появятся новые элементы (так как в прошлом изменений не будет)

Если новый onlineDate меньше чем самый ранний onlineDate твоих отображаемый страниц, то можно не отображать, потому что это не в области видимости.

Очень надеюсь, что описал достаточно понятно, если нет, то дай знать пожалуйста:)
Написано 3 минуты назад