fix: add pagination to GET /vendors endpoint

[EmeditWeb]

Problem

GET /vendors returns all vendors with no pagination or limit. With hundreds of vendors, this endpoint becomes slow.

What To Build

1. Add ?page=1&limit=20 query params
2. Add total count in response meta
3. Add validation that limit ≤ 100

Files To Touch

• src/modules/vendors/vendors.service.ts
• src/modules/vendors/vendors.controller.ts

Acceptance Criteria

• Paginated vendor list
• Default 20 per page, max 100
• Response includes total count
• Build passes

Mandatory Checks

• context/ files read
• npm run build passes
• PR references this issue

[julianvillalba688]

Hi team,

I would love to pick this up as a good first issue! Adding pagination here is a straightforward but crucial fix to keep the /vendors endpoint fast and performant as the platform grows. Here is a brief summary of my experience and how I plan to handle the implementation:

My Experience
As a backend engineer, I regularly design and optimize RESTful APIs using TypeScript and Node.js frameworks. I have extensive experience setting up pagination strategies, handling database query offsets and limits efficiently, and building strict input validation schemas (such as Zod, Joi, or class-validator) to enforce request boundaries and prevent oversized payloads.

Proposed Approach
Controller Layer Input Validation (src/modules/vendors/vendors.controller.ts): I will update the controller to accept page and limit query parameters, ensuring they default to page=1 and limit=20. I'll also add a validation rule to strictly throw a bad request error if a user requests a limit greater than 100.

Service Layer Pagination Logic (src/modules/vendors/vendors.service.ts): I will modify the database query execution to incorporate the correct offset ((page - 1) * limit) and limit bounds. I will implement a dual query execution or count pipeline to fetch both the paginated subset of vendors and the total count of matching records efficiently.

Standardized Meta Response: The endpoint's response envelope will be updated to return the paginated data array along with a meta block containing the total count and structural keys (like current page and total pages) for easier frontend ingestion.

I will review all required context/ documentation before writing code and make sure npm run build passes with zero warnings or errors before submitting the PR. Ready to get started!

[Danielodingz]

Hey maintainer, please i would like to work on this issue.

[faramir07]

I have experience developing scalable backend APIs with NestJS, TypeScript, Node.js, and PostgreSQL. I've built production REST APIs, implemented business logic, and optimized data access for real-world applications.

For this task, I'll inspect the current vendors module, implement server-side pagination with sensible defaults (page=1, limit=20) and validation (limit <= 100), return pagination metadata including the total count, and keep the implementation consistent with the existing architecture. I'll validate the changes by running the build and submit a clean PR that references the issue.

[Iker2522]

Cuento con una amplia experiencia optimizando APIs REST y servicios backend para manejar conjuntos de datos a gran escala de forma eficiente. Migrar endpoints desde la obtención de filas ilimitadas hacia fragmentos deterministas y paginados es un requisito fundamental para prevenir la saturación de memoria tanto en el servidor como en la base de datos, reduciendo drásticamente el tiempo de respuesta inicial (TTFB).

[skaichima]

I'm interested in working on this issue. I have the necessary skills to handle this efficiently and would appreciate it if you could assign it to me. Thanks!

[GoluScriptMage]

Hi! I have submitted a Pull Request (#85) that implements pagination and limit validations for this endpoint. All automated checks builds are passing successfully. Please review when you get a chance. Thanks!

[anidroid1184]

Hi @EmeditWeb, can i work on this issue?