Hablemos de Tipddy Messenger: cómo transformamos el chat de Moodle para funcionar curso por curso

En una plataforma educativa, enviar un mensaje no siempre es suficiente. Cuando un estudiante participa en varios cursos, se relaciona con distintos docentes y comparte la plataforma con cientos de usuarios, también es importante saber con quién está hablando y dentro de qué curso ocurre esa conversación.

Moodle cuenta con un sistema de mensajería robusto y ampliamente utilizado. Sin embargo, su funcionamiento nativo no diferencia las conversaciones según el curso al que pertenecen. En contextos educativos donde un mismo usuario puede participar en múltiples asignaturas, esto puede generar una experiencia menos organizada y dificultar el control de las interacciones.

Fue a partir de este desafío que desarrollamos Tipddy Messenger, una solución que mantiene la mensajería de Moodle, pero incorpora el contexto del curso como una nueva dimensión de la comunicación.

El objetivo no era reemplazar una herramienta que ya funcionaba, sino adaptarla a las necesidades reales de las instituciones educativas, incorporando mayor control, organización y seguridad en cada conversación.

A continuación, te contamos cómo abordamos este desafío y qué decisiones técnicas tomamos para construir una solución que pudiera integrarse con Moodle sin modificar su núcleo.

Un chat no es solo una conversación

En un entorno educativo, una conversación no ocurre en el vacío. Cada mensaje forma parte de un contexto: un curso, una asignatura, un docente y un grupo de estudiantes.

Moodle cuenta con un sistema de mensajería que permite gestionar conversaciones y notificaciones de manera confiable. Sin embargo, su lógica de comunicación considera principalmente a las personas involucradas, sin asociar la conversación a un curso específico.

En una institución donde un estudiante puede estar inscrito en varias asignaturas y relacionarse con distintos docentes, esta diferencia se vuelve relevante. Compartir una misma plataforma no significa necesariamente compartir el mismo espacio de comunicación.

Por eso, uno de los primeros desafíos de Tipddy Messenger fue incorporar el curso como parte de la conversación. La idea era sencilla: que cada interacción estuviera vinculada al contexto académico correspondiente y que los usuarios solo pudieran acceder a los contactos y conversaciones que realmente les correspondían.

El desafío no estuvo solamente en definir estas reglas. Lo realmente complejo fue hacer que se cumplieran de manera consistente en cada punto de acceso al sistema.

Tipddy Messenger cuenta con 13 puertas de entrada en su plugin, y cada una debía respetar las mismas condiciones de seguridad y aislamiento. En otras palabras, no bastaba con crear un chat que funcionara: necesitábamos asegurarnos de que cada conversación ocurriera dentro del contexto correcto.

La solución: tres componentes, una misma lógica

Para resolver este desafío no necesitábamos reemplazar Moodle, sino construir una solución que pudiera trabajar sobre su infraestructura existente sin modificar su núcleo. Así nació Tipddy Messenger, una arquitectura compuesta por tres componentes que trabajan de forma independiente, pero coordinada: Moodle, el plugin y la aplicación de alumnos.

Moodle continúa siendo el núcleo de la solución y la fuente de verdad de la información. Es el que se encarga de almacenar los mensajes y las inscripciones de los usuarios, manteniendo intacto su código base. De esta manera, aprovechamos la estabilidad y las capacidades que Moodle ya ofrece sin intervenir directamente en su funcionamiento interno. El plugin funciona en el servidor y actúa como el intermediario entre Moodle y la aplicación. Su responsabilidad es aplicar las reglas de negocio y seguridad que definimos para Tipddy Messenger.

A través de sus 13 puertas de entrada, verifica cada solicitud y determina si una acción está autorizada o no. Esta capa es especialmente importante porque las reglas de acceso no dependen de lo que ocurra en la interfaz, sino que se validan directamente en el servidor. La aplicación de alumnos, desarrollada en React, es la parte con la que interactúa directamente el usuario. Su objetivo es ofrecer una experiencia de comunicación moderna y fluida, pero sin acceder directamente a Moodle. Todas sus solicitudes pasan primero por el plugin. Esta separación cumple una función clave: la interfaz muestra y solicita información, pero no decide quién puede acceder a ella.

Si las reglas de seguridad estuvieran únicamente en la aplicación, un usuario avanzado podría intentar modificarlas o saltárselas desde el navegador. Al mantenerlas en el servidor, el plugin puede validar cada solicitud independientemente de lo que ocurra en el lado del cliente. De esta forma, cada componente tiene una responsabilidad definida:

Moodle almacena → el plugin valida → la aplicación comunica.

Diseñar midiendo, no suponiendo

En desarrollo de software es fácil caer en una trampa: elegir la alternativa que parece más eficiente antes de comprobar cómo se comporta realmente. Durante la construcción de Tipddy Messenger nos encontramos justamente con una de esas decisiones. Nos topamos con que necesitábamos definir cómo se ejecutarían las operaciones del chat. Ante esto, teníamos dos opciones: podíamos apoyarnos en el motor de mensajería de Moodle o podíamos hacer que el plugin consultara directamente sobre la base de datos. Si bien ambas opciones suenan perfectamente lógicas, para elegir teníamos que realizar una pregunta fundamental.

¿Cuál alternativa tendría realmente un mejor comportamiento bajo las condiciones que necesitábamos?

Nos pusimos manos a la obra, creamos un escenario controlado con 100 alumnos simulados, automatizamos las principales operaciones del chat: abrir contactos, listar conversaciones, leer mensajes, marcar mensajes como leídos y enviar mensajes. La prueba nos permitió diagnosticar casos borde no considerados al principio,  nos topamos con algo que habíamos ignorado por completo: uno de nuestros requerimientos era trabajar en un modelo de reglas de aislamiento de mensajes por curso (esto ya que Moddle normal solo permite que las conversaciones sean generales), esto hizo que el número de consultas efectuadas sobre la base de datos tuviera un aumento considerable. La razón era evidente: la verificación de que cada conversación correspondiera a un curso determinado tenía un considerable costo de rendimiento.

A pesar de esto, no era razón suficiente para considerar descartar la funcionalidad. El aislamiento por curso no era una optimización secundaria ni una característica opcional, era parte fundamental de cómo debía funcionar el sistema. Entonces nos enfocamos no en eliminar, sino en pulir y sofisticar. La decisión de mantener la funcionalidad no buscaba simplemente que el sistema tuviera la menor número de lecturas posibles. la solución debía encontrar un equilibrio entre rendimiento, seguridad, compatibilidad. Ahí es donde encontramos uno de los aprendizajes más importantes del proceso:

Medir no siempre sirve para confirmar que tu primera idea era correcta. A veces sirve para entender cuánto cuesta la decisión correcta.

Por eso, la prueba no quedó como un experimento puntual. Automatizamos el proceso mediante un script de telemetría que nos permite repetir las mediciones bajo distintas cargas y utilizar los resultados para seguir evaluando la salud del sistema. Porque cuando una decisión puede medirse, es mejor no suponer.

La alarma que dejamos puesta

El rendimiento de un sistema no siempre se deteriora de forma evidente. Una nueva funcionalidad o un pequeño cambio en el código puede aumentar silenciosamente las consultas a la base de datos, para evitar este escenario, implementamos una prueba automática de rendimiento funcionando como una alarma. El test funciona de forma que mide cuántas consultas genera el listado de contactos según la cantidad de alumnos del curso. Si una modificación supera el límite definido, el indicador se vuelve rojo y el despliegue queda bloqueado. La idea es simple: mejorar el sistema sin perder el rendimiento que ya alcanzamos, cada cambio debe demostrar que no está comprometiendo lo que ya conseguimos.

Probar antes de romper

Antes de llevar Tipddy Messenger al entorno real, necesitábamos una forma segura de probar cada cambio sin afectar a los usuarios. Para eso creamos un entorno completo y descartable de Moodle mediante contenedores, con la facilidad de un solo comando se pudo levantar una instancia similar a la real, con cursos, profesores, alumnos e historiales de conversación generados automáticamente.

Sobre este entorno aplicamos dos niveles de validación. Las pruebas automáticas de backend verifican las reglas fundamentales del sistema: que un alumno solo pueda contactar a quienes corresponden, que las conversaciones permanezcan aisladas por curso y que se respeten los límites de seguridad. Luego están los Smoke Tests, que simulan el comportamiento de la aplicación React utilizando credenciales de prueba. Con ellos recorremos las 13 puertas de entrada del plugin para comprobar que todo funcione correctamente de principio a fin. De esta forma, se pudo detectar y, más importante, prevenir errores antes de que lleguen al entorno real. 

El punto verde que mentía

Durante las pruebas finales apareció un problema que parecía pequeño: el indicador de conexión. El conocido punto verde mostraba a algunos usuarios como desconectados cuando, en realidad, estaban participando en una conversación. Aunque parezca un detalle menor, este tipo de situación nos puede llevar a distintos escenarios límites que es fundamental evitar de evitar: Por ejemplo,  dos estudiantes realizando una actividad, que uno vea que su compañero está desconectado puede llevar a malentendidos. La experiencia de usuario puede quedar profundamente afectada si no se cuida este tipo de detalles.  

Corregimos el flujo de actualización, en desarrollo todo funcionaba correctamente. Pero al llegar a producción apareció un nuevo problema: la latencia junto a las lecturas en la base de datos se habían visto afectadas considerablemente, perjudicando el rendimiento. ¿Dónde estaba el origen del problema? en el arreglo del punto verde, hicimos un rollback, revisamos la implementación y corregimos el problema desde su origen. Gracias a nuestros entornos descartables, integración continua y control de versiones, pudimos identificar rápidamente el origen.

Este caso dejó una lección clara:

Que algo funcione en desarrollo no significa que esté listo para producción, cada cambio debe probarse no solo por lo que soluciona, sino también por lo que puede afectar.

Esto recién comienza

Tipddy Messenger es solo una parte de un proceso que continúa. Cada proyecto nos permite aprender, probar nuevas ideas y encontrar mejores formas de integrar tecnología, diseño y experiencia de usuario. Seguimos trabajando en nuevas funcionalidades, optimizaciones y soluciones que respondan a las necesidades reales de las organizaciones que confían en nosotros.

Actualmente estamos en marcha blanca analizando la implementación de dos nuevas funcionalidades del chat: la habilitación de un chat grupal para trabajos en grupo (con opciones de adjuntar archivos) y la opción de que el profesor pueda realizar anuncios a sus estudiantes desde la misma plataforma gráfica junto a la automatización del envío de correos.

Si te interesa conocer cómo abordamos estos desafíos, nuestras decisiones de diseño y los proyectos que estamos desarrollando, te invitamos a seguir las publicaciones de Tipddy y acompañarnos en lo que viene. Porque detrás de cada solución hay mucho más que código: hay decisiones, pruebas, aprendizajes y una búsqueda constante por hacer que la tecnología funcione mejor para las personas.