ITA‐Challenges Backend Wiki [Español]
ITA-Challenges es una API que suministra retos de programación (Challenges) para estudiantes, otorgando puntaje a las soluciones aportadas y facilitando mecanismos de tracking para que el usuario pueda comprobar su mejora técnica y evaluación de conocimientos. ITA-Challenges está patrocinado e impulsado por IT Academy, y creado por desarrolladores Java previamente formados en dicha entidad.
La documentación completa de la API (en desarrollo) está disponible en http://dev.ita-challenges.eurecatacademy.org:9080/swagger-ui/index.html
A fin de implementar soporte técnico a los requerimientos funcionales, se siguieron los siguientes pasos:
El aplicativo debería ser capaz de:
- Mantener un repositorio de retos con información que capacite al usuario para resolverlos.
- Permitir a usuarios/as registrar soluciones a dichos retos.
- Validar las soluciones aportadas.
- Registrar usuarios y facilitarle mecanismos de tracking de su progreso.
- ¿Qué es un servicio?
Es el componente de software independiente y desplegable por sí mismo que implementa alguna funcionalidad útil.
- ¿Qué tipo de operaciones ejecuta?
Dos tipos de operaciones: comandos y consultas (queries).
-
¿Qué arquitectura utilizar?
-
Arquitectura de Microservicios (alto nivel): se divide el software en servicios específicos e independientes en sus funciones y tareas.
-
Arquitectura Hexagonal: implementada dentro de cada microservicio.
-
-
¿Por qué arquitectura de microservicios? Dado el escenario técnico del proyecto, se observan algunas ventajas importantes:
-
Escalabilidad: Cada microservicio puede escalar de forma independiente por lo que se optimizan los servicios.
-
Desacoplamiento: Se acelera el desarrollo, implementación y cambios de cada servicio de forma independiente.
-
Diversidad tecnológica: Permite que cada microservicio utilice tecnologias y herramientas distintas.
-
Resiliencia: Si un servicio falla permite que el resto de servicios continuen operando sin interrupción.
-
-
Hexagonal: divide la lógica interna en tres capas principales: dominio, aplicación e infraestructura.
-
Capa de Dominio: Es la capa más interna, contiene la lógica de negocio y las entidades del dominio. Sin dependencias hacia el exterior.
-
Capa de Aplicación: Orquesta el flujo de la aplicación y coordina el uso de la capa de dominio y la capa de infraestructura. Ésta se comunica con la capa de dominio y la capa de infraestructura.
-
Capa de Infraestructura: Es la capa más externa y se encarga de todas las operaciones de entrada y salida (persistencia de datos, comunicación con otros sistemas, interfaz de usuario, etc).
-
-
Spring Boot y Arquitectura Hexagonal:
-
Controller: Capa de adaptadores primarios o de entrada en la arquitectura hexagonal. Se gestionan las solicitudes entrantes y las pasa a la capa de servicios para su procesamiento.
-
Service: Capa de aplicación en la arquitectura hexagonal. Se encarga de la lógica de negocio y coordina las operaciones entre la capa de entrada (Controller) y la capa de salida (Repository).
-
Repository: Capa de adaptadores secundarios o de salida en la arquitectura hexagonal. Se responsabiliza de la persistencia de datos y cualquier otra operación de salida del sistema.
-
- Challenge: Suministra la información relativa de los desafíos. El microservicio se comunicará con Score que es quien otorgará la puntuación.
- User: Permite asignar desafíos favoritos y soluciones nuevas.
- Document: Se usa para conectarse a la documentación de cada uno de los restantes microservicios. Implementa [Circuit Breaker Pattern].(https://microservices.io/patterns/reliability/circuit-breaker.html) para tolerancia a fallos.
- Auth: Recibe el token de autenticación desde la API Gateway y comunica si es o no válido. El resto de funcionalidades relacionadas con la autenticación se gestionan con un SSO (Single Sign On).
- Score: Contiene el núcleo de la lógica de negocio del proyecto: compilar, ejecutar (en un entorno seguro) y asignar una puntuación a las soluciones presentadas por usuarios/as del aplicativo.
- API Gateway: Proporciona un único punto de entrada para el cliente, redirigiendo cada petición al microservicio que se corresponda (véase http://microservices.io/patterns/apigateway.html).
Para abordar este punto clave, se decidió utilizar ZeroMQ por su facilidad de uso. Su uso en la comunicación entre microservicios es fundamental debido a su capacidad para proporcionar patrones de mensajería asincrónica, que permite a los microservicios interactuar sin necesidad de estar constantemente conectados. ZeroMQ soporta varios modelos de transporte, incluyendo TCP, IPC y multicast, que facilita la configuración de la comunicación entre microservicios independientemente de su ubicación. Además, proporciona una serie de características que son esenciales en un entorno de microservicios, como la tolerancia a fallos, la capacidad de manejar grandes volúmenes de tráfico y la posibilidad de establecer patrones de mensajería complejos, como solicitudes de respuesta, publicación-suscripción y push-pull.
La aplicación, implementa patrones de mensajería REQ-REP, actualmente se utilizan 3 servidores y 3 clientes para llevar a cabo estas solicitudes.
