Chatbots Adapter
“Una API para Todos los Frameworks NLU”
Construyendo un chatbot para Telegram. Rasa es potente pero requiere trabajo real para configurarlo y entrenarlo. DialogFlow es mas facil pero te ata al proveedor. IBM Watson tiene excelentes funciones empresariales. Azure Bot Services se integra con el ecosistema de Microsoft. Y si pudieras cambiar el backend NLU sin reescribir tu bot?
Eso es lo que hace este proyecto. Una unica API REST con FastAPI que se comunica con cuatro proveedores NLU diferentes a traves de una interfaz unificada. Tu bot envia un mensaje, el adaptador lo enruta al proveedor configurado y la respuesta vuelve en un formato consistente.
Arquitectura
La API expone endpoints para enviar mensajes, gestionar conversaciones y configurar que proveedor NLU maneja cada intencion. Cada proveedor (Rasa, DialogFlow, IBM Watson, Azure) tiene su propio modulo adaptador que implementa la misma interfaz. El despachador selecciona el adaptador correcto segun la configuracion y enruta la solicitud.
El proyecto se ejecuta en Docker con una base de datos PostgreSQL para el estado de las conversaciones. Se desplego en Heroku con un pipeline GitLab CI/CD (antes de migrar todo a GitHub Actions). Un docker-compose.yml hace que el desarrollo local sea trivial: un comando y todo el stack esta funcionando.
Que haria diferente hoy
Este proyecto esta archivado. Cumplio su proposito: alimento dos bots de Telegram y me enseno a construir una API REST de produccion con FastAPI, Docker y CI/CD. Mirando hacia atras con unos cuantos anos mas de experiencia:
Soporte asincrono en toda la aplicacion. FastAPI soporta async de forma nativa, pero el adaptador usaba llamadas HTTP sincronas a los proveedores NLU. Hoy haria cada adaptador de proveedor completamente asincrono con httpx.AsyncClient y pooling de conexiones.
Reemplazar Heroku con Kubernetes. El despliegue en Heroku funciono, pero el tier gratuito tenia arranques en frio y recursos limitados. Hoy esto se ejecutaria en mi cluster K3s con health checks adecuados, despliegues progresivos y observabilidad.
Anadir trazabilidad con OpenTelemetry. El adaptador enruta solicitudes a cuatro proveedores diferentes. Sin trazabilidad, depurar una respuesta lenta o fallida significa buscar en logs de multiples sistemas. La trazabilidad distribuida mostraria exactamente donde se pasa el tiempo.
Versionado de API desde el principio. Los endpoints cambiaron a medida que se anadian nuevos proveedores. Un prefijo /v1/ habria salvado a los bots consumidores de cambios incompatibles.
Tests. Este proyecto fue construido antes de que adoptara el desarrollo guiado por pruebas. Tiene 182 commits y ninguna suite de tests. Hoy cada proyecto que escribo empieza con tests.