Mi Estrategia de Comandos de Bot para Telegram & Discord

Hola a todos, Marcus aquí de ai7bot.com. Es 13 de marzo de 2026 y he estado lidiando últimamente con un problema en particular que apuesto a que muchos de ustedes que están construyendo bots han enfrentado o están a punto de enfrentar. Estoy hablando de gestionar los comandos e interacciones de los bots a través de múltiples plataformas sin perder la cabeza. Específicamente, he estado profundizando en Telegram y Discord, tratando de averiguar cómo mantener las cosas en orden cuando tu bot necesita hacer cosas similares en ambos lugares.

Durante un tiempo, mi enfoque era lo que llamaría “duplicación por fuerza bruta.” Si mi bot tenía un comando /help en Telegram, escribía el código para eso. Luego, si necesitaba un comando similar !help en Discord, prácticamente copiaba y pegaba y ajustaba. Esto funcionó por un tiempo, especialmente cuando mis bots eran pequeños y específicos. Pero a medida que crecieron, y a medida que empecé a agregar más funciones, se convirtió en una pesadilla. Actualizar un comando significaba actualizar dos, tres o incluso más lugares. ¿Correcciones de errores? Multiplica por el número de plataformas. Era lento, propenso a errores y, francamente, le quitaba la alegría a construir.

Recuerdo una noche tarde, probablemente impulsado por demasiado café y no suficiente sueño, tratando de depurar por qué el comando /status de mi bot de Telegram mostraba información desactualizada mientras que el comando !status del bot de Discord estaba perfectamente bien. Resultó que había actualizado la fuente de datos en un lugar y me había olvidado por completo del otro. Ese fue mi momento “¡aha!”. Tenía que haber una mejor manera. Y esa mejor manera, para mí, ha sido inclinarme fuertemente hacia un enfoque más unificado basado en API para la lógica central del bot, abstraiendo lo específico de la plataforma tanto como sea posible.

El Dolor de Cabeza del Bot Multiplataforma: Un Verdadero Inconveniente

Seamos honestos, construir un bot para una sola plataforma ya es lo suficientemente desafiante. Te enfrentas a las peculiaridades de la API, límites de tasa, expectativas de los usuarios y la imprevisibilidad general de internet. Añade una segunda, tercera o incluso cuarta plataforma a la mezcla y de repente no solo estás construyendo un bot; estás construyendo una capa de traducción, un motor de sincronización y un sistema de gestión de salud mental para ti mismo.

Mi primer bot, “WeatherBot 2000” (original, ¿verdad?), comenzó en Telegram. Era simple: escribías /weather <city> y te daba las condiciones actuales. ¡Genial! Luego un amigo preguntó si podía ponerlo en Discord. “¡Claro!” dije, confiado. Copié la lógica para obtener el clima, le puse un envoltorio de comando de Discord y boom, “WeatherBot 2000” también estaba en Discord, respondiendo a !weather <city>. Misión cumplida, o eso pensé.

Luego vinieron las peticiones: “¿Puede mostrar un pronóstico a 3 días?” “¿Puede usar Celsius en lugar de Fahrenheit?” “¿También puede decirme la calidad del aire?” Cada nueva característica significaba tocar el código en al menos dos lugares. La función de pronóstico, por ejemplo, requería cambiar la forma en que analizaba la respuesta de la API del clima y cómo formateaba la salida. Hacer esto dos veces, una para el Markdown de Telegram y otra para el Markdown ligeramente diferente de Discord (o embeds para un aspecto más atractivo), era tedioso. No era solo copiar y pegar; era re-implementar la lógica de presentación.

¿Por qué Separar las Preocupaciones? Se Trata de la Cordura.

El núcleo del problema era que mi “lógica empresarial” (obteniendo datos del clima, procesándolos) estaba entrelazada con mi “lógica de presentación” (cómo se ve en Telegram, cómo se ve en Discord). Este es un problema clásico en el desarrollo de software, y la solución, como aprendí de la manera difícil, es separar estas preocupaciones. Piénsalo así:

• Lógica Central: Esto es lo que tu bot hace. Para WeatherBot, realiza llamadas a la API de un servicio meteorológico, analiza la respuesta JSON y extrae datos relevantes. Esta parte debe ser independiente de la plataforma.
• Adaptadores de Plataforma/Lógica de Presentación: Esto es cómo tu bot habla en cada plataforma. Son las llamadas a la API de Telegram, las llamadas a la API de Discord, manejando prefijos de comando, formateando mensajes con Markdown o embeds, enviando archivos, etc.

Cuando mantienes estas partes separadas, puedes actualizar tu lógica central de obtención del clima una vez, y beneficia instantáneamente tanto a tus bots de Telegram como a los de Discord. Si Telegram lanza una nueva opción de formato de mensaje llamativa, solo necesitas actualizar tu adaptador de Telegram. La parte de obtención del clima permanece intacta.

Construyendo un Núcleo Unificado con APIs: Mi Ejemplo de “WeatherBrain”

Después de mi pesadilla de depuración, decidí reconstruir “WeatherBot 2000” desde cero, pero esta vez con una separación clara. Creé una pequeña API interna para la funcionalidad central de mi bot. La llamo “WeatherBrain” (sigo trabajando en los nombres, ¿de acuerdo?).

WeatherBrain es simplemente una aplicación Python Flask simple (podría ser cualquier cosa, incluso un conjunto de funciones en una biblioteca, pero una API facilita escalar y probar de forma independiente). Expone endpoints como /api/weather?city=london&units=metric y /api/forecast?city=london&days=3. Cuando es llamada, realiza una solicitud a una API externa real de clima (como OpenWeatherMap o AccuWeather), procesa los datos y devuelve una respuesta JSON limpia y consistente.

Aquí tienes un vistazo simplificado a cómo podría verse un endpoint de WeatherBrain:

# weather_brain_api.py (ejemplo simplificado de Flask)
from flask import Flask, request, jsonify
import requests
import os

app = Flask(__name__)

# Esto idealmente estaría en una configuración o variable de entorno
WEATHER_API_KEY = os.environ.get("OPENWEATHER_API_KEY") 
OPENWEATHER_URL = "http://api.openweathermap.org/data/2.5/weather"

@app.route('/api/weather', methods=['GET'])
def get_current_weather():
 city = request.args.get('city')
 units = request.args.get('units', 'metric') # 'metric' o 'imperial'

 if not city:
 return jsonify({"error": "Se requiere el parámetro de ciudad"}), 400

 params = {
 'q': city,
 'appid': WEATHER_API_KEY,
 'units': units
 }

 try:
 response = requests.get(OPENWEATHER_URL, params=params)
 response.raise_for_status() # Lanza una excepción para errores HTTP
 data = response.json()

 # Procesar y simplificar los datos
 weather_info = {
 "city": data['name'],
 "country": data['sys']['country'],
 "description": data['weather'][0]['description'].capitalize(),
 "temperature": data['main']['temp'],
 "feels_like": data['main']['feels_like'],
 "humidity": data['main']['humidity'],
 "wind_speed": data['wind']['speed']
 }
 return jsonify(weather_info)

 except requests.exceptions.RequestException as e:
 app.logger.error(f"Error al obtener el clima para {city}: {e}")
 return jsonify({"error": "No se pudo obtener los datos del clima"}), 500
 except KeyError as e:
 app.logger.error(f"Error de clave en los datos meteorológicos para {city}: {e}")
 return jsonify({"error": "Formato de datos meteorológicos inesperado"}), 500

if __name__ == '__main__':
 app.run(debug=True, port=5001)

Ahora, tanto mi bot de Telegram como mi bot de Discord no hablan directamente con OpenWeatherMap. Hablan con WeatherBrain. ¡Esto es una gran victoria! Si quiero cambiar de OpenWeatherMap a AccuWeather, solo cambio el código en weather_brain_api.py. Los bots ni siquiera saben que ha sucedido.

Bots de Telegram y Discord: Convertirse en Clientes Ligeros

Con WeatherBrain manejando el trabajo pesado, el código real de mis bots de Telegram y Discord se volvió mucho más simple. Ahora actúan como “clientes ligeros” o “adaptadores.” Su trabajo es puramente:

1. Escuchar comandos (por ejemplo, /weather <city> o !weather <city>).
2. Analizar el comando y extraer argumentos.
3. Realizar una solicitud HTTP a WeatherBrain.
4. Recibir la respuesta JSON de WeatherBrain.
5. Formatear esa respuesta JSON en un mensaje específico de la plataforma.
6. Enviar el mensaje de vuelta al usuario.

Aquí tienes un ejemplo simplificado de cómo podría verse el adaptador de Telegram:

# telegram_bot.py (simplificado)
import telebot
import requests
import os

TELEGRAM_BOT_TOKEN = os.environ.get("TELEGRAM_BOT_TOKEN")
WEATHER_BRAIN_API_URL = "http://localhost:5001/api/weather" # O la URL de tu API desplegada

bot = telebot.TeleBot(TELEGRAM_BOT_TOKEN)

@bot.message_handler(commands=['weather'])
def send_weather(message):
 try:
 args = message.text.split(maxsplit=1)
 if len(args) < 2:
 bot.reply_to(message, "Por favor proporciona una ciudad. Ejemplo, `/weather London`")
 return

 city = args[1]
 
 # Llamar a la API interna
 response = requests.get(WEATHER_BRAIN_API_URL, params={'city': city, 'units': 'metric'})
 response.raise_for_status()
 weather_data = response.json()

 if "error" in weather_data:
 bot.reply_to(message, f"Error: {weather_data['error']}")
 return

 # Formatear para Telegram
 output = (
 f"*{weather_data['city']}, {weather_data['country']}*\n"
 f"Clima: {weather_data['description']}\n"
 f"Temperatura: {weather_data['temperature']:.1f}°C (Sensación térmica {weather_data['feels_like']:.1f}°C)\n"
 f"Humedad: {weather_data['humidity']}%\n"
 f"Viento: {weather_data['wind_speed']:.1f} m/s"
 )
 bot.reply_to(message, output, parse_mode='Markdown')

 except requests.exceptions.RequestException as e:
 bot.reply_to(message, "Lo siento, no pude obtener el clima en este momento. Parece que mi cerebro está tomando una siesta.")
 print(f"Error al llamar a la API de WeatherBrain: {e}")
 except Exception as e:
 bot.reply_to(message, "Ocurrió un error inesperado. Por favor intenta nuevamente más tarde.")
 print(f"Error general en el bot de Telegram: {e}")

bot.polling()

Y el adaptador de Discord se vería muy similar, solo utilizando la biblioteca Discord.py (o lo que prefieras) para manejar comandos y formatear mensajes con la sintaxis específica de Discord (por ejemplo, embeds para mensajes más ricos).

La clave aquí es que ambos bots están obteniendo los mismos datos estructurados de WeatherBrain. Simplemente los presentan de manera diferente. Esto reduce drásticamente el código duplicado y facilita mucho las adiciones de características o correcciones de errores.

Más Allá de los Comandos: Webhooks y Eventos

Este enfoque impulsado por API no se limita solo a comandos. ¿Qué pasa si tu bot necesita reaccionar a eventos externos? Supongamos que tienes un bot de monitoreo que verifica el tiempo de actividad de un sitio web. Cuando el sitio web se cae, tu servicio de monitoreo puede enviar un webhook a tu WeatherBrain (o a una API separada llamada “NotifierBrain”). Esta API decide entonces qué plataformas notificar (Telegram, Discord, correo electrónico, SMS) y qué mensaje enviar, pasando los datos de alerta estructurados a cada adaptador de plataforma.

Ahí es donde realmente brilla el poder. Tu API central se convierte en la única fuente de verdad para la inteligencia de tu bot, y los componentes específicos de la plataforma son solo canales de comunicación.

Conclusiones Accionables para Tu Próximo Proyecto de Bot

Si estás construyendo un bot, especialmente uno que anticipas expandir a múltiples plataformas o agregar características complejas, considera estos puntos:

1. Aisla Tu Lógica Principal: Antes de tocar una API específica de la plataforma, anota (o codifica) lo que tu bot fundamentalmente hace. ¿Qué datos necesita? ¿Qué cálculos realiza? Esta es tu “mente”.
2. Construye una API Interna (Incluso una Sencilla): Ya sea una aplicación Flask, un servicio FastAPI, o simplemente un módulo de Python bien organizado con funciones claras, crea una capa que encapsule tu lógica principal y devuelva datos estructurados y consistentes (JSON es excelente para esto). Esto lo hace testeable y reutilizable.
3. Trata los Bots Específicos de la Plataforma como Adaptadores: Su tarea es traducir la entrada del usuario en llamadas a tu API interna y luego traducir las respuestas de la API interna en mensajes apropiados para esa plataforma. Deben ser “delgados” – lógica mínima, máxima comunicación.
4. Planea para el Manejo de Errores: Cuando tienes múltiples capas (bot de plataforma -> API interna -> API externa), los errores pueden ocurrir en cualquier etapa. Asegúrate de que cada capa maneje correctamente las fallas de la capa inferior y proporcione retroalimentación informativa (pero no excesivamente técnica) al usuario.
5. Considera el Despliegue: Si tu API interna es un servicio separado, necesitarás desplegarla en algún lugar. Servicios como Heroku, Render, o incluso un pequeño VPS pueden alojar estos microservicios. Asegúrate de que tus bots de plataforma puedan acceder a tu API interna (por ejemplo, si está ejecutándose localmente, necesitan estar en la misma red o ser accesibles a través de una URL pública).
6. Comienza Pequeño, Itera: No necesitas construir una arquitectura de microservicios masiva desde el primer día. Comienza con una función principal, aísla y luego construye tu primer adaptador de plataforma. A medida que añadas más características o plataformas, naturalmente expandirás tu API interna.

Adoptar este enfoque me ha ahorrado incontables horas de depuración y me ha permitido escalar mis bots de manera mucho más efectiva. La configuración inicial puede parecer un poco más trabajo, pero créeme, los beneficios a largo plazo en mantenibilidad, escalabilidad y, francamente, en tu propia cordura, realmente valen la pena. ¡Feliz construcción de bots!

🕒 Published: March 25, 2026