💬 Minichat Flask

Escala del Proyecto

Descripción General

Ejercicio de introducción a Flask en cinco pasos. El resultado final es un chat multiusuario que funciona, en 32 líneas, y esa brevedad es justamente lo que hace el ejercicio interesante.

El servidor tiene dos rutas. La raíz acepta GET para renderizar la plantilla con los mensajes y POST para añadir uno nuevo, validando que ni el usuario ni el texto estén vacíos y redirigiendo después para evitar el reenvío del formulario. Cada mensaje guarda usuario, texto y hora con strftime.

La segunda ruta, /mensajes, devuelve la lista completa como JSON con jsonify. Es la que permite que el cliente refresque el chat consultándola periódicamente, sin WebSockets. Los mensajes viven en una lista en memoria: no hay base de datos.

Tecnologías Utilizadas

Las Dos Rutas

• GET / — renderiza la plantilla pasándole la lista de mensajes.
• POST / — recoge usuario y mensaje del formulario, los limpia con strip(), descarta los vacíos, añade la hora con strftime("%H:%M:%S") y redirige a la raíz.
• GET /mensajes — devuelve la lista completa como JSON mediante jsonify. Es el endpoint que consulta el cliente para actualizarse.

Progresión del Ejercicio

• 001Miniflask. El servidor más pequeño posible: una ruta que devuelve texto.
• 002Contador. Primer estado que persiste entre peticiones.
• 003Guardo mensajes. Recepción de datos por POST y almacenamiento en memoria.
• 004Chat. Versión funcional con plantilla y envío de mensajes. 20 líneas.
• 005Superchat. Se añade la marca de hora y el endpoint JSON /mensajes que habilita el refresco por polling. 32 líneas.

Qué Aprendí

• Que un chat "en tiempo real" no necesita WebSockets: consultar un endpoint JSON cada segundo es suficiente para un grupo pequeño, y es mucho más simple de montar.
• Que el patrón POST-redirect-GET evita que recargar la página reenvíe el último mensaje.
• Que guardar los mensajes en una lista en memoria significa que se pierden al reiniciar el servidor, y que además falla con varios procesos de Flask. Es la limitación evidente del ejercicio y el motivo por el que existen las bases de datos.
• Que separar la ruta que renderiza HTML de la que devuelve JSON es el germen de la separación entre servidor y API que uso en los proyectos grandes del portafolio.
• Que 32 líneas pueden ser un programa completo, y que eso vale más como lección que como código.

Mi Rol

Autor del ejercicio. Práctica individual de la asignatura de programación en el lado del servidor.

Estado del Proyecto

Ejercicio académico completado, con los cinco pasos y las plantillas en el repositorio de apuntes.

Código y Enlaces

Ruta dentro del repositorio: Apuntes/010-Programción en el lado del servidor/025-Chat/