Patrón repositorio para centralizar fetch

Centralizar la lógica de peticiones a un API en JavaScript evita que un cambio en la respuesta del servidor te obligue a modificar decenas de archivos. El patrón repositorio resuelve ese problema agrupando toda la interacción con el API en una sola clase, lo que facilita mantenimiento, pruebas y migraciones cuando trabajas con fetch en proyectos sin frameworks.

Por qué usar el patrón repositorio con fetch

Cuando usas fetch directamente en distintos archivos, terminas repitiendo la misma petición en múltiples lugares. Si el API cambia un campo (por ejemplo, id pasa a identificador), tienes que cazar cada ocurrencia.

El repositorio actúa como una capa de abstracción: una sola clase concentra las peticiones a /products, /categories y cualquier otra entidad. Si algo cambia, lo cambias en un solo lugar.

¿Qué es el patrón repositorio? Es un patrón de diseño que encapsula la lógica de acceso a datos en una clase dedicada, separando esa responsabilidad del resto de tu aplicación.

Qué ventajas concretas obtienes

• Centralización: un único punto de verdad para hablar con el API.
• Mantenibilidad: actualizas el contrato del API sin tocar la UI.
• Testabilidad: pruebas la lógica de red en un solo módulo.

Cómo crear un ProductRepository en JavaScript vanilla

La implementación arranca creando un archivo nuevo dentro de la carpeta js llamado repositories.js e importándolo desde index.html justo después del mock data [01:30].

Dentro del archivo defines una clase ProductRepository, uno de los pilares de la programación orientada a objetos en JavaScript. El constructor recibe la URL base del API y la guarda como atributo de instancia [02:15].

javascript class ProductRepository { constructor(url) { this.url = url; }

async getProducts() { const response = await fetch(${this.url}/products); const responseData = await response.json(); return responseData; } }

window.productRepository = new ProductRepository(API_URL);

Fíjate en un detalle: la URL base se pasa sin slash final para evitar la doble concatenación cuando se une con /products [03:40].

Cómo exponer el repositorio en el navegador

Como trabajas con JavaScript vanilla y sin framework, asignas la instancia al objeto window. Esto hace que window.productRepository esté disponible en cualquier parte de tu sitio y también desde la consola del navegador, algo muy útil para depurar.

¿Por qué usar una clase y no funciones sueltas? Porque la clase encapsula estado (la URL) y comportamiento (los métodos como getProducts) en una sola unidad reutilizable e instanciable.

Cómo depurar peticiones fetch con breakpoints en el navegador

Una vez cargado repositories.js, abres las DevTools y vas a la pestaña Sources. Ahí encuentras el archivo y puedes colocar un breakpoint en cualquier línea [05:20].

Desde la consola pruebas el repositorio así:

javascript const repo = window.productRepository; await repo.getProducts();

Cuando la ejecución llegue al breakpoint, el navegador se detiene. Puedes pasar el cursor sobre cada variable para inspeccionar su valor en ese momento, ver qué URL se está construyendo, y revisar la respuesta del API antes de continuar.

Cómo inspeccionar la respuesta del API paso a paso

Para ver los datos limpios, conviene separar el response y el responseData en dos variables. Así puedes pausar entre la respuesta cruda y el JSON ya parseado.

Desde la consola, con la ejecución pausada, puedes manipular los datos en vivo:

• responseData[4] te muestra el quinto producto de la lista.
• responseData[4].images[0] devuelve la primera imagen de ese producto.
• Si te equivocas con el nombre del atributo (por ejemplo, image en vez de images), la consola te lo indica de inmediato.

Este flujo de trabajo convierte al navegador en un laboratorio: pruebas, rompes, ajustas y vuelves a probar sin recargar tu lógica de negocio.

Diferencia entre retornar response y retornar JSON

Un detalle clave: fetch no devuelve los datos directamente. Devuelve un objeto Response que necesitas transformar.

Si tu método retorna el response tal cual, quien lo consuma tendrá que llamar .json() por su cuenta. Mejor que el repositorio devuelva ya los datos parseados con response.json(), así el resto del código recibe un objeto listo para usar.

Esto refuerza la idea del repositorio: abstrae los detalles de transporte y entrega solo lo que la aplicación necesita.

Qué sigue para conectar el API con tu template

Con el repositorio listo, el siguiente paso es implementar el verbo GET para traer la lista real de productos y pintarlos en el template, reemplazando el mock data que se usaba como auxiliar.

Si ya implementaste tu propio repositorio, cuéntame en los comentarios qué entidad encapsulaste primero y qué dificultades encontraste al exponerlo en window.