Cuando un bot de WhatsApp empieza a crecer, mantener toda la lógica en un solo archivo deja de ser viable. Aplicar una arquitectura modelo vista controlador (MVC) te permite separar responsabilidades, escalar el proyecto y trabajar en equipo sin pisarte con otros desarrolladores. Esto es clave si tu bot va a integrar nuevos servicios, tipos de mensajes o funciones de la API de Meta.

¿Por qué separar la lógica de un bot de WhatsApp en varios archivos?

Un archivo único como server.js funciona al inicio, pero se vuelve un cuello de botella cuando llegan nuevas funciones. Al dividir el código por dominio, sabes exactamente dónde está cada error y dónde tocar para agregar mejoras.

La idea es simple: cada archivo tiene un objetivo claro. Si mañana necesitas agregar un nuevo tipo de mensaje, vas directo a WhatsAppService y modificas solo ahí. Nada más.

¿Qué es la arquitectura MVC en un bot? Es un patrón que separa el código en modelos, vistas y controladores. En este bot se traduce en carpetas como config, controllers, routes y services, cada una con una responsabilidad específica.

¿Cómo se estructura el proyecto dentro de la carpeta src?

Dentro de src se reparte la lógica que antes vivía en server.js [2:00]. La nueva estructura queda así:

• config: maneja las variables de entorno en un solo lugar para no repetirlas en cada archivo.
• controllers: contiene webhookController, encargado de recibir y responder solicitudes hacia y desde Meta.
• routes: define las rutas que Express va a servir, conectándolas con el controlador.
• services: agrupa messageHandler y WhatsAppService, que ejecutan acciones específicas con la API.

Esta separación por dominio facilita identificar errores y trabajar en equipo sin que varias personas modifiquen el mismo archivo a la vez.

¿Qué hace el archivo app.js como punto de entrada?

app.js es ahora la raíz de la aplicación [4:30]. Inicializa Express, carga las variables de entorno desde config, conecta las rutas del webhook y levanta el servidor con un mensaje de log que confirma dónde se está ejecutando.

Es un archivo corto, limpio, sin lógica de negocio. Su único trabajo es orquestar.

¿Cómo funcionan las rutas y el webhook controller?

El archivo de rutas tiene dos acciones clave [5:30]:

• router.post('/webhook'): dirige los mensajes entrantes hacia webhookController.handleIncoming.
• router.get('/webhook'): ejecuta verifyWebhook para validar la conexión con Meta usando un token.

El webhookController concentra entonces dos responsabilidades. La primera es filtrar los mensajes que llegan desde la API y decidir qué hacer con ellos. La segunda es responder al handshake de verificación que Meta exige para confirmar que tu servidor es legítimo.

¿Cómo se manejan los mensajes con messageHandler y WhatsAppService?

Dentro de services viven las dos piezas que ejecutan el trabajo real con la API de WhatsApp [7:00].

messageHandler recibe el mensaje ya filtrado y revisa su tipo. Si es de tipo texto, prepara una respuesta y dispara dos acciones a través de WhatsAppService: replicar el mensaje al usuario y marcarlo como leído.

WhatsAppService está construido como una clase. Su método sendMessage recibe el número del usuario, el cuerpo del mensaje y el messageId. Dentro de un bloque try/catch arma la solicitud HTTP a la API usando el apiToken que viene desde config, envía la información y maneja cualquier error.

¿Qué hace el WhatsAppService? Es la clase que ejecuta llamadas directas a la API de WhatsApp. Envía mensajes, marca como leídos y centraliza la autenticación con el token, para que ningún otro archivo tenga que conocer esos detalles.

¿Qué ventajas trae esta estructura para escalar el bot?

Pensar la arquitectura desde el inicio te ahorra rehacer el proyecto más adelante. Algunos beneficios concretos:

• Localización rápida de errores por archivo y dominio.
• Trabajo paralelo en equipo sin conflictos en el mismo archivo.
• Incorporación sencilla de nuevos tipos de mensajes o templates de la API.
• Reutilización de configuraciones como el apiToken desde un solo lugar.
• Base lista para producción y para nuevas funciones que Meta agregue a su API.

Hay código que todavía se repite entre sendMessage y markAsRead, y eso se puede optimizar más adelante refactorizando los métodos hacia una función común de solicitud HTTP. Es parte del proceso: primero separas, luego depuras.

El archivo server.js en la raíz se mantiene como referencia, pero deja de ser funcional. La aplicación ahora se sirve desde app.js. Compáralos lado a lado y observa cómo cada bloque encontró su lugar. ¿Tú estructurarías las carpetas de otra forma? Cuéntalo en los comentarios.