Я тут досматриваю очередной публичный собес и решил поделиться своими мыслями, касаемо пагинации.
Когда ребята проектировали реализацию списка объявлений, естественно затронули тему пагинации. Георгий предложил использовать пагинацию через Cursor и кажется он забыл сказать про одно важное преимущество этого способа – Гибкость. В чём же собственно гибкость? Попробую объяснить.
Давайте на примере пагинации через Page, посмотрим как мы взаимодействуем с бэком. Обычно в запросе мы передаём параметры вида
page=1, size=20. При такой реализации бэкенд жестко привязан именно к этим параметрам и такому формату. Если допустим на бэке нужно будет поменять какую-то внутреннюю логику, то с большей вероятностью, это либо не получится сделать, либо нужно будет вносить правки на клиенте.А теперь давайте посмотрим как мы взаимодействуем с бэком через Cursor. При использовании способа через Cursor, мы в запросе передаём полученный с бэка Cursor – обычно это строка, в которой закодированны какие-то данные(уникальный id, token, либо что-то подобное). При запросе первой пачки мы ничего не знаем о Cursor, передаём дефолтное значение(null или пустую строку), в ответ бэк нам присылает актуальный Cursor, который мы передаём в следующем запросе и так до тех пор, пока не закончатся данные.
При таком взаимодействии, бэкенд сам формирует Cursor, запихивает туда данные, нужные ему для дальнейшей работы и при необходимости может менять свою внутреннюю логику без правок на клиенте, что собственно довольно гибко.
То есть, теоретически можно сделать так: в курсор запихать
Cursor="page=1", закодировать, вернуть в ответе клиенту, клиент в свою очередь отправит этот Cursor на бэк, бэк декодирует Cursor, вернёт следующую пачку данных и Cursor="page=2". Таким образом клиент будет взаимодействовать с бэком через курсорную пагинацию, но внутри бэк будет использовать постраничную. Это чисто пример для наглядности, так делать не надо 😁