Recabar requisitos técnicos: ¿Qué cosas necesitamos para poner en marcha el Bot?

[igponce]

• [x] Desarrollo
  • [X] Versión GO (1.16 = latest)
  • [x] Información sobre el lenguaje: https://github.com/JJ/aprende-go (libro)
  • [x] Librerias que podemos usar
    • [x] wrapper de la API de TG: https://github.com/go-telegram-bot-api/telegram-bot-api
  • [X] Documentación de API Telegram: https://core.telegram.org/api
• [x] Arquitectura
  • [X] Lenguaje de Programación: GO.
  • [x] Almacenamiento / persistencia: Sistema de archivos. Ficheros locales y base de datos mongoDB.
  • [x] Requisitos legales (GDPR, etc) - quedan fuera del alcance (desarrollo ágil, no implementación concreta)
    • [X] Certificados - No hace falta un certificado de una CA.
    • [x] Apikeys / permisos / tokens
    • [x] Hablar en Telegram con @bofather y mandar mensaje /newbot -> Con esto crea un apikey para usar (cada uno debería tener la suya)

[delightfulagony]

Por ejemplo, esta librería es wrapper de la API de TG: https://github.com/go-telegram-bot-api/telegram-bot-api ❤️❤️❤️

[murcian0]

En cuanto a la infrastructura, en la clase de hoy JJ ha comentado que los bots de Telegram funcionan mediante Hooks.

[igponce]

Persistencia de los datos

Podemos usar solamente un log para los datos. Es decir, trabajar sin usar una base de datos. ¿Cómo?

Una opción sería usar Kafka (kafka.apache.org):

• Tendríamos un topic por usuario
• Cada topic tendría una retención (tiempo de vida) y tamaño fijos. Kafka mantiene automáticamente el tamaño de los
• Se puede tener usuarios premium que tengan más TTL y espacio. No es un requisito pero...

Ventajas

• La gestión del espacio la hace Kafka, no nosotros.
• No hay que purgar ficharos. Ni la base de datos.
• Es rápido (1 millón de registros en menos de 1 segundo).
• No impone ningún formato de almacenamiento (puede ser binario, blob, etc)
• Se puede elegir la forma de particionar los datos por todo el cluster.

Inconvenientes

• ¿Cuántos topics puede aguantar un broker de Kafka? En Linkedin tenían sobre los 5K topics por broker. Por encima de eso puedes tocar los límites del sistema operativo (open files, buffers, etc)
• Hay que leer todos los mensajes de los topics de para mostrar el/los que se quiere. Por suerte Kafka es rápido.
• Borrados. Para poder borrar datos de dentro hay que usar Kafka como un log clave/valor (log compaction)
• No hay índices. No se pueden ordenar los datos. Llegan en el orden en el que te los da Kafka. Suelen estar ordenados por tiempo de creación o actualización.
• Está pensado para tener varios brokers. Se puede usar sólo uno para desarrollar.

[igponce]

He abierto un issue (#11) para ver las posibilidades de arquitectura.

[igponce]

Decisión: es un piloto. No vamos a tomar datos personales.

[igponce]

Telegram no necesita el certificaco de una CA "estándar" para mandar callbacks. Basta con un certificado self-signed. Actualizo item.

[igponce]

Quito checkbox [X] Modulos a implementar. Eso viene en un hito más adelantado

[igponce]

Esto queda fuera del alcance del hito 5:

Cada uno desarrolla sobre su propio equipo con sus APIKeys propias. En caso de necesitarr callbacks, se registran contra las IP de maquinas que tengamos cada uno.

• [ ] Infraestructura (depende de la Arquitectura)

  • [ ] Qué necesitamos para correr el bot

  • [ ] Dónde podemos ejecutar el bot

  • [ ] Que hay que provisionar

    • [ ] One-off
    • [ ] Recurrentemente (certificados? dominios? etc)

Para desarrollo no necesitamos comprar certificados, dominios, ni nada que se le parezca. Para la ejecución pueden hacer falta pero la decisión no corresponde aquí.

[igponce]

Voy a cerrar este ISSUE. Creo que tenemos todo lo que necesita el HITO 5.