Ningún endpoint del API pagina ni filtra: todos los GET devuelven la tabla completa (BaseRepository.findAll).
El front descarga tablas completas y las cruza en el navegador. La página de reportes (apps/web/src/app/admin/reportes/page.tsx) carga 9 tablas.
productAgg hace find lineales dentro de un loop (reportes/page.tsx:76-78), con costo O(n·m).
Qué estamos pagando hoy
Hoy funciona porque hay pocos datos. Con meses de ventas, reportes, historial y POS se van a volver lentos, y cada carga transfiere toda la base al navegador (incluidos datos que el usuario no necesita ver).
Arreglo propuesto
Paginación y filtros (?from=&to=&status=) en los listados grandes: ventas, pagos, movimientos de inventario y de caja
Endpoints de reportes agregados en el API (GET /reports/sales?from=&to=, etc.) calculados con SQL
Mientras tanto, reemplazar los find dentro de loops por Map en reportes/page.tsx
Techo de esta ronda
Paginación en los listados que crecen con el tiempo y los reportes de ventas. Fuera: catálogos chicos (categorías, inventarios, usuarios), que pueden seguir sin paginar.
Superficie
API (apps/api)
Módulos
API / backend, Web / frontend, Reportes, Punto de venta (POS)
Esfuerzo
L — partir; este issue solo cubre el primer corte
Riesgo de no tocarlo
Medio
### Qué es la deuda
- Ningún endpoint del API pagina ni filtra: todos los `GET` devuelven la tabla completa (`BaseRepository.findAll`).
- El front descarga tablas completas y las cruza en el navegador. La página de reportes (`apps/web/src/app/admin/reportes/page.tsx`) carga 9 tablas.
- `productAgg` hace `find` lineales dentro de un loop (`reportes/page.tsx:76-78`), con costo O(n·m).
### Qué estamos pagando hoy
Hoy funciona porque hay pocos datos. Con meses de ventas, reportes, historial y POS se van a volver lentos, y cada carga transfiere toda la base al navegador (incluidos datos que el usuario no necesita ver).
### Arreglo propuesto
- [ ] Paginación y filtros (`?from=&to=&status=`) en los listados grandes: ventas, pagos, movimientos de inventario y de caja
- [ ] Endpoints de reportes agregados en el API (`GET /reports/sales?from=&to=`, etc.) calculados con SQL
- [ ] Mientras tanto, reemplazar los `find` dentro de loops por `Map` en `reportes/page.tsx`
### Techo de esta ronda
Paginación en los listados que crecen con el tiempo y los reportes de ventas. Fuera: catálogos chicos (categorías, inventarios, usuarios), que pueden seguir sin paginar.
### Superficie
API (apps/api)
### Módulos
API / backend, Web / frontend, Reportes, Punto de venta (POS)
### Esfuerzo
L — partir; este issue solo cubre el primer corte
### Riesgo de no tocarlo
Medio
Nolberto
was assigned by Carlos2026-10-02 20:06:05 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Qué es la deuda
GETdevuelven la tabla completa (BaseRepository.findAll).apps/web/src/app/admin/reportes/page.tsx) carga 9 tablas.productAgghacefindlineales dentro de un loop (reportes/page.tsx:76-78), con costo O(n·m).Qué estamos pagando hoy
Hoy funciona porque hay pocos datos. Con meses de ventas, reportes, historial y POS se van a volver lentos, y cada carga transfiere toda la base al navegador (incluidos datos que el usuario no necesita ver).
Arreglo propuesto
?from=&to=&status=) en los listados grandes: ventas, pagos, movimientos de inventario y de cajaGET /reports/sales?from=&to=, etc.) calculados con SQLfinddentro de loops porMapenreportes/page.tsxTecho de esta ronda
Paginación en los listados que crecen con el tiempo y los reportes de ventas. Fuera: catálogos chicos (categorías, inventarios, usuarios), que pueden seguir sin paginar.
Superficie
API (apps/api)
Módulos
API / backend, Web / frontend, Reportes, Punto de venta (POS)
Esfuerzo
L — partir; este issue solo cubre el primer corte
Riesgo de no tocarlo
Medio