Иногда команда фронтенда или другие потребители API просят выводить в эндпоинтах общее число объектов. Если в качестве хранилища используется MongoDB, постарайтесь избежать этого: такое поведение эндпоинтов может значительно их замедлить.
Я говорю о тех случаях, когда ответ API похож на тот, что расположен ниже, — тогда ждите беды:
{
"total": XX,
"limit": ZZ,
"offset": YY,
"objects": [...]
}
Если коллекция достаточно большая, а запрос достаточно тяжёлый, count будет работать непозволительно долго. Запрос find при этом может работать быстро: ему ведь надо вернуть всего‑то десяток объектов. count будет перебирать весь набор объектов, подходящих под условия запроса.
Иногда добавление дополнительных условий в запрос, которые должны замедлить его (к примеру, поиск по регулярному выражению), но при этом сильно сокращают количество подходящих объектов, может даже ускорить ответ от API. find так и будет возвращать десяток объектов, а count будет обрабатывать гораздо меньше объектов.
Так какие же есть решения?
Во‑первых, если есть возможность поменять формат API, меняйте его. Результат со ссылками на предыдущие и следующие результаты (как это делает Facebook API) может оказаться значительно быстрее:
{
"pre": "link-to-previous-x-objects",
"next": "link-to-next-x-objects",
"limit": x,
"objects": [...]
}
Второй возможный вариант — кэшировать total. Тогда API будет работать примерно как поисковые системы: иногда сообщать клиенту, что в базе есть больше объектов, чем на самом деле. Во многих случаях это нормально — особенно когда консистентность весьма условная.
В любом случае всё это имеет значение, если коллекция достаточно большая, объекты приличного размера, а запрос довольно сложный. Во всех остальных случаях можно делать всё, что заблагорассудится. Стоит только не забывать, что сервис может вырасти, а переделывать API потом будет очень сложно и дорого.