Cuando se trabaja con Node.js y MongoDB, existen dos patrones comunes para crear una paginación:

• Use .skip(X).limit(Y) al consultar los datos: básicamente definimos un tamaño por página (“límite”) y jugamos con el cálculo del valor “saltar”
• Use {_id: {$lt: FIRST_MONGO_ID, $gt: LAST_MONGO_ID}} y .sort(_id: -1}: aquí mantenemos una referencia del primer y último elemento mostrado y siempre jugamos con encontrar elementos entre esos valores

Algunos artículos hablando de esto:

• https://docs.mongodb.com/manual/reference/method/cursor.skip/#pagination-example
• https://medium.com/swlh/mongodb-pagination-fast-consistent-ece2a97070f3
• https://www.codementor.io/@arpitbhayani/paginación-rápida-y-eficiente-en-mongodb-9095flbqr

Aquí está el problema que tenemos: una lista paginada de elementos de dos colecciones mongo diferentes, una con alrededor de 400.000 elementos y otra con casi 2 millones de elementos. A medida que crece el número de elementos también crece el tiempo de solicitud. Veamos algunos números.

Para la primera página:

• Tiempo de solicitud: 16.37 seg
• Respuesta: {items: [...], page: 1, pageSize: 10, total: 14225}

Para la última página:

• Tiempo de solicitud: 37.61 seg
• Respuesta: {items: [...], page: 1426, pageSize: 10, total: 14255}

Algunos detalles sobre la implementación:

• skip + limit es la estrategia de paginación utilizada aquí
• Calculamos el total de elementos que coincidirían con la consulta incluso cuando solo devolvemos el tamaño de página definido * el número de páginas que queremos devolver cada vez

La mejora se basó en cambios funcionales y técnicos.

Los cambios funcionales se basaron en cómo manejar una larga lista de resultados. Por ejemplo, cuando busca algo demasiado genérico en Google, no obtendrá todas las páginas disponibles al principio (el número total de elementos), pero obtiene una cantidad definida de ellos, y cuando avanza en la lista, obtener nuevas páginas (otro número de elementos). Esto tiene mucho sentido porque estaría pagando un alto precio (el tiempo para calcular todos los elementos disponibles) por algo que probablemente no se necesitará. Si hay demasiados elementos, debe mejorar los términos para la búsqueda y obtener menos elementos.

Los cambios técnicos están relacionados con cómo Mongo realiza la búsqueda y cómo manejamos los datos. Algunas cosas para cambiar o validar:

• Tener los índices correctos y realizar la consulta basada en esos campos
• Utilizar una proyección en la consulta. No obtenga todos los elementos de la colección. Obtenga solo las propiedades que va a necesitar para la lista (cuando necesite el resto de las propiedades, simplemente realice una consulta simple por id y obténgalas)
• Cada vez que buscamos una cantidad limitada de elementos para actualizar el total, en mi caso para 100 elementos (lo que significa 10 páginas de 10 elementos). el codigo es algo así:

Veamos la mejora del tiempo de solicitud

Para la primera página:

• Tiempo de solicitud: 732ms
• Respuesta: {items: [...], page: 1, pageSize: 1, total: 100}

Para la última página visible (al cargar esta aparecerá otra):

• Tiempo de solicitud: 1.87 seg
• Respuesta: {items: [...], page: 20, pageSize: 10, total: 542}

Está claro que la mejora es muy alta y también lo es la productividad para el cliente.

Entonces, como podemos ver aquí, los cambios funcionales son más importantes que los cambios técnicos. Cada vez, necesitamos evaluar cómo vamos a utilizar la tecnología para obtener la mejor solución para los usuarios. En este caso, reducir el tiempo para mostrar datos es más importante que decirle al usuario cuántos elementos tenemos en total (tenemos tantos que se vuelve menos importante que una respuesta de tiempo correcta). No necesitamos hacer grandes y complejos cambios técnicos cada vez, tal vez necesitemos “pensar fuera de la caja” más a menudo.

Espero que esto ayude a alguien.