yovi_es2a

Mecánica del Juego: El sistema debe representar un tablero triangular dividido en casillas hexagonales. Debe permitir la colocación de fichas por turnos y detectar automáticamente si un jugador ha conectado los tres lados del tablero (victoria).

Modos de Juego: Se requiere soportar dos tipos de partidas:

Gestión de Usuarios: El sistema gestiona la autenticación mediante el registro e inicio de sesión. Además, garantiza la persistencia de los datos, manteniendo un perfil actualizado de cada jugador.

Historial y Persistencia: El sistema registra de forma automática el resultado de cada partida finalizada. Los usuarios disponen de un panel de consulta donde pueden visualizar su historial de victorias y derrotas, permitiendo el filtrado de los registros por fecha, tipo de oponente y tamaño del tablero.

Ranking Global: El sistema mantiene una tabla de clasificación pública con los diez mejores jugadores. La puntuación se calcula automáticamente a partir del historial de partidas de cada usuario, ponderando las victorias según la dificultad del oponente derrotado. El usuario logueado puede ver su posición resaltada dentro del ranking.

Plataforma: La aplicación es plenamente accesible desde navegadores web modernos. El sistema se distribuye mediante contenedores Docker, lo que garantiza un despliegue ágil y consistente en cualquier entorno que lo soporte.

Protocolo y Formato: HTTP y JSON.

Responsabilidad: Gestiona la persistencia y consulta de datos sensibles: perfiles de usuario, autenticación, almacenamiento del historial de partidas y cálculo del ranking global.

Integración: Permite a agentes externos y al frontend la consulta de estadísticas, historial y ranking mediante endpoints REST estándar (GET /ranking).

Protocolo y Formato: HTTP, JSON y notación YEN.

Responsabilidad: Procesa la lógica algorítmica del Juego Y, validación de reglas en tiempo real y ejecución de estrategias de IA.

Interoperabilidad: Expone el método GET /play que permite el intercambio de jugadas serializadas en notación YEN, facilitando la competición de bots externos contra el motor desarrollado en Rust.

Protocolo: HTTP, HTML y JSON.

Soporta la interacción directa de los usuarios con el frontend web.

Funciones principales: registro, selección de estrategia, ejecución de movimientos y consulta de estadísticas.

Formato HTML para visualización y JSON para llamadas internas o APIs de frontend-backend.

Protocolo: Conexión interna mediante el driver de mongodb desde el servicio users.

Almacena: perfiles de usuario, historial de partidas, ranking, relaciones de amistad y grupos.

Frontend:

Backend:

Motor de Juego:

Persistencia y Datos:

Pruebas de Rendimiento:

Pruebas y Aseguramiento de Calidad:

Monitorización y Análisis de Rendimiento: Grafana y Prometheus: Herramientas seleccionadas para la monitorización en tiempo real del rendimiento del sistem para identificar cuellos de botella y optimizar la experiencia del usuario.

Partida: La entidad central que mantiene el estado del tablero triangular, el turno actual y la validación de las reglas. Utiliza algoritmos de búsqueda para detectar si se han conectado los tres lados del tablero.

Tablero: Un tablero triangular dividio en celdas hexagonales.

Coordenadas: Debido a la naturaleza hexagonal del tablero, se utiliza un sistema de coordenadas específico para identificar cada celda y calcular adyacencias de forma eficiente.

Jugador: Puede ser un usuario humano autenticado o un Bot.

1. Dificultad del rival: No todas las victorias valen lo mismo. Ganar al bot aleatorio otorga un multiplicador bajo (x1), ganar a otros jugadores humanos da más puntos (x5), y derrotar a la IA más avanzada (Monte Carlo) otorga el multiplicador máximo (x7).

2. Número de victorias: Es el factor principal; cuantas más veces derrotes a un rival concreto, más puntos acumulas.

3. Filtro anti-suerte (Confianza estadística): Si un jugador juega una sola partida contra la IA difícil y la gana por suerte, tendría un "100% de victorias". Para evitar que esto rompa el ranking, el sistema exige un mínimo de volumen. Si juegas pocas partidas, recibes solo una fracción de los puntos. Necesitas jugar unas 30 partidas contra un mismo rival para que el sistema confíe en tu nivel y te dé el 100% de tus puntos.

4. Bonus de eficacia: Si ganas muchas partidas y pierdes muy pocas contra un mismo oponente, el sistema te premia con un pequeño porcentaje extra de puntos.

Visualización del Tablero: Dado que el tablero hexagonal no es común, la interfaz debe traducir las coordenadas lógicas (x, y, z) a una posición visual en pantalla (píxeles). Se emplearán ayudas visuales para resaltar las celdas adyacentes y los movimientos válidos.

Feedback Inmediato: La interfaz bloquea visualmente acciones ilegales antes de enviarlas al servidor para mejorar la reactividad, aunque la validación final siempre reside en el backend.

Diseño Adaptable: La interfaz se adapta a diferentes tamaños de tablero, asegurando que el tablero triangular sea jugable tanto en su tamaño mínimo (4) como máximo (30).

Validación en el Servidor: Aunque la web avise de errores. Todas las jugadas se validan de nuevo en el servidor para evitar trampas.

Autoridad del Servidor: El frontend es solo una capa de presentación. El estado real de la partida reside en los microservicios. Esto evita que los usuarios manipulen el cliente para ganar.

Microservicios Desacoplados: El sistema no es un único bloque, sino que está dividido en servicios independientes (Node.js y Rust). Esto permite aislar la carga de procesamiento matemático del juego de la gestión de sesiones de usuario.

Comunicación Directa (Cliente-Servidor): El frontend (React) actúa como orquestador de las peticiones, comunicándose directamente mediante HTTP/REST con el servicio correspondiente (Puerto 3000 para usuarios, Puerto 4000 para juego) sin intermediarios, optimizando la latencia de red.

Comunicación (JSON): Todas las partes del sistema intercambian información utilizando el formato estándar JSON, lo que garantiza la compatibilidad entre el frontend y el backend.

Gestión de Errores: Se utilizan los códigos estándar de la web para indicar claramente si una acción ha funcionado o por qué ha fallado, facilitando la corrección de problemas.

Persistencia de Datos: La información crítica, como los usuarios registrados y el historial de partidas terminadas, se almacena de forma segura en una base de datos MongoDB.

Estrategia de Pruebas: Para asegurar la calidad y el rendimiento del sistema bajo estrés, se ha integrado la herramienta Gatling en el flujo de desarrollo. Los scripts de simulación (escritos en Scala) se encuentran dentro del repositorio en la carpeta PruebaCarga. Esto permite a cualquier desarrollador del equipo levantar el entorno local de Docker y lanzar los tests de concurrencia para validar que sus cambios no han degradado el rendimiento del servidor antes de realizar un despliegue.

Estatus: Aceptado.

Contexto: Se necesitaba persistir información de usuarios y su historial de partidas.

Decisión: Se utilizará MongoDB como base de datos, en lugar de una base de datos relacional como PostgreSQL o MySQL.

Justificación: Consideramos una mejor decisión el uso de una base de datos NoSQL como MongoDB debido a la simplicidad del modelo de datos y la ausencia de relaciones complejas. MongoDB permite almacenar documentos JSON, lo que simplifica mucho la gestión de la información de los usuarios y su historial de partidas sin necesidad de diseñar esquemas rígidos o realizar migraciones frecuentes.

Alternativas consideradas: PostgreSQL / MySQL → Descartadas por añadir complejidad innecesaria (esquemas rígidos, migraciones) para un modelo de datos tan simple.

Consecuencias:

Estatus: Aceptado.

Contexto: El usuario necesita consultar miles de registros. Realizar peticiones por cada pulsación de tecla (live search) saturaría el servicio de usuarios.

Decisión: Se implementa un estado temporal en el Frontend para el input de "Rival" y una ejecución "Lazy" de la búsqueda. La petición a la API solo se dispara al pulsar el botón "Buscar".

Consecuencias: Mejora del rendimiento de red y reducción de carga en MongoDB.

Estatus: Aceptado.

Contexto: El sistema necesita almacenar contraseñas de usuarios de forma segura en MongoDB. Era necesario elegir un algoritmo de hashing que protegiera las credenciales ante posibles filtraciones de la base de datos.

Decisión: Se utiliza Argon2id mediante la librería argon2 de Node.js para hashear las contraseñas antes de persistirlas y para verificarlas en el login.

Justificación: Investigando un poco descubrimos que Argon2id es actualmente la recomendación del OWASP (Open Web Application Security Project) para el almacenamiento seguro de contraseñas. A diferencia de alternativas como bcrypt o SHA-256, Argon2id está diseñado para ser resistente tanto a ataques de fuerza bruta por GPU como a ataques de canal lateral, gracias a su configuración de coste de memoria y tiempo. Su variante id combina las ventajas de Argon2i (resistencia a side-channel) y Argon2d (resistencia a GPU), siendo la opción más equilibrada y segura.

Alternativas consideradas:

Consecuencias:

Estatus: Aceptado.

Decisión: Se implementa un mecanismo de identificación de usuario en cliente, basado en el almacenamiento del identificador (_id) en localStorage, el cual se envía en cada petición HTTP mediante el header personalizado X-User.

Justificación: El flujo funciona de la siguiente manera: tras un login exitoso, el microservicio de usuarios devuelve el _id (identificador único en MongoDB). Este valor se almacena en el localStorage del navegador bajo la clave userId. En las peticiones posteriores que requieren identificación (como consultar historial, perfil o ranking), el frontend incluye este valor en el header X-User.

Alternativas consideradas:

Consecuencias:

Estatus: Aceptado.

Contexto: Al añadir el ranking global se necesitaba una métrica de ordenación justa. Las alternativas triviales (victorias totales, ratio de victorias) tienen sesgos bien conocidos: la primera ignora la dificultad del rival, la segunda infla a jugadores con muy pocas partidas.

Decisión: Se utiliza la siguiente fórmula, calculada en tiempo real en GET /ranking agregando la colección GameRecords:

Desglose matemático de los factores:

C(10)        = 1 − exp(−10/10)  ≈ 0.632
bonus        = 1 + 5/10          = 1.5
aporte       = 7.0 · 5 · 0.632 · 1.5  ≈ 33.18 puntos

Alternativas consideradas:

Consecuencias:

Estatus: Aceptado.

Contexto: En una arquitectura de microservicios, como vimos más tarde en clase, es habitual centralizar el tráfico entrante a través de un gateway que actúe como punto único de entrada. Para el momento de tomar esta decisión teníamos que definir el cómo hacer la API pública para los bots externos.

Decisión: Se descarta el uso de un gateway centralizado. En su lugar:

Justificación: Consideramos que añadir una gateway sería complicar la arquitectura de forma innecesaria en vista de la poca cantidad de endpoints disponibles y la simplicidad de estos. Además, en vista de que nuestra aplicación no está diseñada para manejar un amplio tráfico de bots externos o usuarios, resolvimos tomar la opción más sencilla de implementar.

Alternativas consideradas:

Consecuencias:

Estatus: Aceptado.

Contexto: Durante el análisis de código estático con SonarCloud, se identificaron vulnerabilidades críticas de seguridad. Estas ocurrían al inyectar parámetros del usuario directamente en las rutas de las peticiones HTTP (fetch).

Decisión: Se rechaza el uso de comentarios de evasión (// NOSONAR) o listas de bloqueo de caracteres. En su lugar, se implementa una política de Validación por Lista Blanca (Allowlist).

Justificación: Se ha centralizado la seguridad en una función (sanitizeParam) que utiliza una expresión regular estricta (^[a-zA-Z0-9_-]+$). Esto asegura matemáticamente que cualquier dato que viaje hacia los microservicios sea inofensivo, bloqueando la petición en el cliente si se detectan caracteres de inyección (/, . o scripts).

Alternativas consideradas:

Consecuencias:

Estatus: Aceptado.

Contexto: Se decide añadir sistema YOVI un componente social básico que permitiera a los jugadores identificar a otros usuarios como amigos y participar en grupos para organizar partidas privadas.

Decisión: Se implementa un sistema de relaciones sociales con las siguientes características:

Justificación: La decisión de implementar amigos y grupos como relaciones directas (sin solicitudes ni invitaciones) responde a la prioridad de simplicidad del proyecto. No se consideró necesario un flujo de solicitud-aceptación para amigos ni un sistema de invitaciones para grupos en esta versión.

Alternativas consideradas:

Consecuencias:

Árbol de Calidad: Una representación jerárquica que desglosa los atributos de calidad de alto nivel.

Escenarios de Calidad: Descripciones detalladas que permiten evaluar si el sistema cumple con las expectativas de los stakeholders.

Petición POST a /login para autenticarse en el sistema.

Petición POST a /game/new para iniciar una partida local contra un invitado.

Intercambio de 4 turnos: Peticiones POST a /game/{id}/move simulando la colocación de 4 fichas en el tablero.

Rendición: Nueva petición a /game/{id}/move enviando la acción de rendición de uno de los jugadores.

Petición POST a /savegame, ejecutada automáticamente por el sistema al volver al menú para registrar el resultado final en el historial.

Volumen total: Se ejecutaron un total de 950 peticiones HTTP.

Tiempos de respuesta (Rendimiento): El servidor mostró una velocidad excelente. El 95º percentil de tiempo de respuesta se mantuvo por debajo de los 350ms, y la gran mayoría de peticiones OK se resolvieron en menos de 50ms.

Tasa de Éxito y Errores:

Quality Gate (Passed): El código cumple todos los requisitos definidos para poder ser liberado a producción.

Cobertura (Coverage): Se ha alcanzado un 86.06% de cobertura mediante tests automatizados.

Mantenibilidad y Seguridad: El análisis certifica que la arquitectura es sólida, reportando 0 vulnerabilidades críticas y un nivel de código duplicado ínfimo (0.52%).