Добрый день. Мне нужно отобразить на фронте таблицу данных с пагинацией. Ищу пример пагинации в Монге, чтобы отсылать туда запросы с фронта. Наподобие https://stackoverflow.com/a/44857996/5524590, см. конец кода.

Спасибо. Мне пока нравится моя ссылка больше, там $slice кусочка коллекции от и до от+число строк на страницу.

вот нормальный туториал если еще нужно https://evdokimovm.github.io/javascript/nodejs/mongodb/pagination/expressjs/ejs/bootstrap/2017/08/20/create-pagination-with-nodejs-mongodb-express-and-ejs-step-by-step-from-scratch.html

Есть способ вернуть часть коллекции от и до, помимо skip и limit? Пытаюсь приспособить для этого $slice.

При перемещении по пагинации таблицы, т. е. при кликах по кнопках пагинации, отправлять запрос в БД и подбирать очередные 10 (пока фиксированное число) записей. Сейчас для начала пишу запрос, который бы возвращал документы с индексами от и до, хочется написать его без использования skip и limit, т. к. они пробегают по всей коллекции.

Возможно передать в $match в aggregate пустой объект {}? Чтобы получить все документы в коллекции. Аналогичнo коллекция.find({}).

Что то не пойму речь о паджинации идёт или нет. Сколько не видел разных вариантов, все skip и limit используют. Хоть в мускуле хоть в оракле

А зачем вам вообще стейдж с матчем в пайплайне, если вам нужны все документы?)

Сейчас пробую получать очередные 10 документов по клику на кнопку пагинации. Цифра на этой кнопке, т. е. номер текущей страницы, это const currentPage в коде ниже. router.get('/test/subs/:current_page', async (req, res) => { const RESULTS_PER_PAGE = 10; const currentPage = req.params.current_page; try { const docs = await Subscription .aggregate([ { "$facet": { "records": [ { "$match": {} }, { "$skip": (currentPage - 1) * RESULTS_PER_PAGE }, { "$limit": RESULTS_PER_PAGE } ], "count": [ { "$count": "count" } ] } } ]); res.status(200).json({ docs }); } catch(ex) { console.log('error fetching docs from Subscription:', ex.message); res.status(500).json({ message: 'error fetching docs from Subscription' }); } }); Этот серверный роут будет получать запросы от фронта и возвращать текущий кусочек коллекции и размер всей коллекции.

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

Размер коллекции не меняется. Лимит документов на страницу таблицы на фронте будет чуть позже, это будет выпадающиее меню "столько-то строк" (отображать). Как кешиpовать count?

Node.js на сервере, React на фронте.

Node.js 1-поточен по дефолту.

Глобальный объект на беке?

Ну тогда если у вас одна нода, т.е. нет необходимости синхронизации кэша между разными нодами приложения, то сделайте глобальный объект с полем count и в нем храните кэшированное значение количества документов

зачем

Всем привет. Подскажите как лучше хранить данные из 1-20 тысячи элементов массива (цифры, спарсенные айди)? У меня в голове крутятся такие варианты: текстовый файл, mongodb таблица где будет тип Object и туда загонять, но не знаю разумно ли это, ну или создавать для каждого элемента свой документ в таблице. Использоваться это будет только в скрипте, одновременно будет работать с этими данными 1 процесс. Что скажете?

текстовые файлы редко являются удачным вариантом. возможно, sqlite или rocksdb будет более простым решением, если для вашего языка к ним есть биндинги

в npm скорее всего есть биндинги

если вам не нужен поиск по значению, а доступ по ключам простой, key/value хранилища типа rocksdb или другое embedded будет достаточно. возможно в ноду уже что-то встроено если у вас сложные запросы, разные измерения по которым вы хотите делать выборки, то sqlite

Всем привет. Подскажите как лучше хранить данные из 1-20 тысячи элементов массива (цифры, спарсенные айди)? У меня в голове крутятся такие варианты: текстовый файл, mongodb таблица где будет тип Object и туда загонять, но не знаю разумно ли это, ну или создавать для каждого элемента свой документ в таблице. Использоваться это будет только в скрипте, одновременно будет работать с этими данными 1 процесс. Что скажете?

А чем RocksDB лучше Redis? По сути мне нужно список айди поместить и извлекать потом по 1-2, но нужно знать где остановились

меньше двигающихся частей

это бибилиотека, так что вы его встраиваете в своё прилоежние

в вашей задаче было про 1 процесс

сомневаюсь

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

В ближайшие пару месяцев может и не будет больших объемов, но потом будет и что, переписывать логику всю?

В ближайшие пару месяцев может и не будет больших объемов, но потом будет и что, переписывать логику всю?

быстрее запилите, быстрее поймёте что вам реально надо

у меня обычно это выглядит как-то так