Repetir lógica en cada función de un servicio es una de las trampas más comunes al integrar APIs externas. Si trabajas con la API de WhatsApp Cloud y notas que tu archivo whatsappService.js repite el mismo axios.post, los mismos headers y la misma URL en cada método, este refactor con un módulo http-requests te va a ahorrar dolores de cabeza y hará tu código más escalable.

Por qué duplicar lógica en WhatsApp Service rompe la escalabilidad

Cuando cada función que envía mensajes, audio, video, contactos o ubicación repite el mismo bloque de código, cualquier cambio mínimo se multiplica por todos lados.

Imagina que mañana graph.facebook.com cambia a graph.whatsapp.com o a .meta.com. Tendrías que tocar cada función, una por una. Y si solo tienes acceso por consola al servidor, sin tu IDE favorito ni la lupa de buscar y reemplazar, el riesgo de dejar un endpoint viejo es altísimo.

Esto va contra el principio DRY (Don't Repeat Yourself), una regla básica que dice que cada pieza de conocimiento debe existir en un solo lugar dentro de tu sistema [00:14].

¿Qué es el principio DRY en programación? Es una regla que indica no repetir lógica ni datos en múltiples lugares del código. Si necesitas cambiar algo, debes poder hacerlo en un solo archivo.

Cómo crear el servicio sendToWhatsApp paso a paso

La idea es centralizar toda la comunicación con la API en un único archivo reutilizable. Vamos por partes.

Estructura de carpetas y dependencias iniciales

Dentro de services crea una carpeta nueva llamada http-requests y, dentro, un archivo sendToWhatsApp.js [02:33]. Ese nombre deja claro que ahí vive el servicio encargado de hacer las solicitudes HTTP.

Las importaciones que necesitas son dos:

• axios, para ejecutar la petición.
• config, tu archivo central de variables de entorno (ojo, no confundir con el config de dotenv).

Construir la función async con baseUrl y headers

Declara una constante sendToWhatsApp como función async que recibe data por parámetro. Dentro, define:

• baseUrl: la URL completa del endpoint, idealmente leída desde config.baseUrl para controlarla por variable de entorno.
• headers: un objeto con Authorization que toma el token desde config.apiToken.

Así, el día que cambie el dominio o rotes el token, lo modificas en el .env y listo. Sin tocar la lógica del servicio.

Manejar la petición con try catch y axios

Dentro del bloque try haces la llamada con axios pasándole un objeto de configuración con method: 'POST', url: baseUrl, los headers y la data que recibiste. Devuelves response.data con un return.

En el catch capturas el error y lo imprimes con console.error. Es la misma estructura que antes vivía repetida en cada método [05:14].

js import axios from 'axios'; import config from '../../config.js';

const sendToWhatsApp = async (data) => { const baseUrl = config.baseUrl; const headers = { Authorization: config.apiToken, };

try { const response = await axios({ method: 'POST', url: baseUrl, headers, data, }); return response.data; } catch (error) { console.error(error); } };

export default sendToWhatsApp;

No olvides actualizar tu archivo .env.example agregando BASE_URL y demás variables nuevas, para que cualquier persona que clone el repo sepa qué configurar [06:53].

Cómo migrar los métodos existentes al nuevo servicio

Una vez que sendToWhatsApp está listo, toca limpiar whatsappService.js. Elimina las importaciones de axios y config que ya no necesitas y deja solo:

js import sendToWhatsApp from './http-requests/sendToWhatsApp.js';

Refactor del método para enviar mensajes de texto

Quita el try/catch completo. En su lugar, arma solo el objeto data con la estructura que pide la API:

• messaging_product: 'whatsapp'.
• to: el destinatario.
• text: el cuerpo del mensaje.
• context con message_id: opcional, solo si quieres responder citando un mensaje previo.

Luego un simple await sendToWhatsApp(data) y terminaste [08:09].

Refactor del método markAsRead

Misma receta. Construyes el objeto data con messaging_product, to y el message_id que recibes como parámetro, y haces await sendToWhatsApp(data). La función queda compacta, legible y sin lógica HTTP repetida.

¿Cuándo conviene mover una llamada axios a un servicio aparte? Cuando dos o más funciones repiten la misma URL, headers o estructura de petición. Centralizar evita inconsistencias y facilita cambiar la API en un solo lugar.

Qué ganas con esta separación de responsabilidades

El beneficio no es solo estético. Cuando haces clic en sendToWhatsApp desde tu editor y usas Go to Definition, te lleva directo al archivo donde vive la lógica HTTP. Eso acelera el debugging y la lectura del código.

Además, separar capas te da:

• Un único punto para actualizar la URL base o el token.
• Métodos de servicio enfocados solo en armar el payload correcto.
• Variables de entorno controladas desde un panel o .env, sin tocar archivos JS.
• Un código más fácil de testear, porque puedes mockear sendToWhatsApp en lugar de mockear axios en cada test.

Tu reto ahora es aplicar el mismo patrón al resto de métodos: envío de imágenes, audios, ubicación, contactos y plantillas. Cuando termines, cuéntame en los comentarios qué método te costó más migrar y por qué.