Real Time API Integration: My Life Is A Game

(1)

Real Time API Integration: My Life Is A Game

Israel Lozano Callado

Grado en Ingeniería Informática Java EE

Antoni Oller Arcas 01/2023

(2)

Esta obra está sujeta a una licencia de Reconocimiento-NoComercial-SinObraDerivad a3.0 España de Creative Commons

(3)

Licencias alternativas (elegir alguna de las siguientes y sustituir la de la página anterior)

A) Creative Commons:

Esta obra está sujeta a una licencia de Reconocimiento-NoComercial-SinObraDerivad a3.0 España de Creative Commons

Esta obra está sujeta a una licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 España de Creative Commons

Esta obra está sujeta a una licencia de Reconocimiento-NoComercial 3.0 España de Creative Commons

Esta obra está sujeta a una licencia de Reconocimiento-SinObraDerivada 3.0 España de Creative Commons

Esta obra está sujeta a una licencia de Reconocimiento-CompartirIgual 3.0 España de Creative Commons

Esta obra está sujeta a una licencia de Reconocimiento 3.0 España de Creative Commons

B) GNU Free Documentation License (GNU FDL)

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3

(4)

or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

A copy of the license is included in the section entitled "GNU Free Documentation License".

C) Copyright

Reservados todos los derechos. Está prohibido la reproducción total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la impresión, la reprografía, el microfilme, el tratamiento informático o cualquier otro sistema, así como la distribución de ejemplares mediante alquiler y préstamo, sin la autorización escrita del autor o de los límites que autorice la Ley de Propiedad Intelectual.

(5)

FICHA DEL TRABAJO FINAL

Título del trabajo: Real Time API Integration: My Life Is A Game

Nombre del autor: Israel Lozano Callado

Nombre del consultor: Antoni Oller Arcas

Fecha de entrega (mm/aaaa): 01/2023

Área del Trabajo Final: Java EE

Titulación: Grado en Ingeniería Informática

Resumen del Trabajo (máximo 250 palabras):

El objetivo de este proyecto es el análisis y realización de pruebas de concepto de diversas soluciones para la optimización de comunicaciones entre sistemas, basados en APIs, con tal de determinar una arquitectura basada en los escenarios más habituales en la actualidad.

Para conseguir cumplir este objetivo, se han hecho diversos estudios para las diferentes tecnologías usándolas en el desarrollo de nuestras aplicaciones o servicios, para comparar y testear su comportamiento. Así mismo como reto personal se quiere llevar a la práctica de forma real y completa todos los conocimientos y competencias adquiridos en las asignaturas del itinerario del grado de Ingeniería del software.

Las tecnologías que se han estudiado son servicios REST para generar nuestra API, Generación de eventos a través de Kafka, securización y control de nuestra API mediante Oauth y sistema de caché usando Redis.

Al final, decidir qué usar y qué no depende de los sistemas que queremos integrar. Las soluciones estudiadas para este TFG han demostrado ser útiles para solucionar problemas específicos pero fácilmente escalables para otras soluciones.

(6)

Abstract (in English, 250 words or less):

The objective of this project is the analysis and proof of concept of various solutions for the optimization of communications between systems, based on APIs, in order to determine an architecture based on the most common scenarios today.

In order to achieve this objective, various studies have been carried out for the different technologies, using them in the development of our applications or services, to compare and test their behavior. Likewise, as a personal challenge, we want to put into practice in a real and complete way all the knowledge and skills acquired in the subjects of the itinerary of the Software Engineering degree.

The technologies that have been studied are REST services to generate our API, event generation through Kafka, security and control of our API through Oauth and cache system using Redis.

In the end, deciding what to use and what not depends on the systems we want to integrate. The solutions studied for this TFG have proven to be useful to solve specific problems but easily scalable for other solutions.

Palabras clave (entre 4 y 8):

Real Time API Integration

(7)

Índice

1. Introducción 2

1.1 Objetivos del Trabajo 6

1.1.1 Funcionalidades generales 6

1.1.2 Stack Tecnológico 7

1.2 Enfoque y método seguido 8

1.3 Planificación del Trabajo 9

1.4 Breve sumario de productos obtenidos 9

1.5 Breve descripción de los otros capítulos de la memoria 10

2. Análisis 11

2.1 Roles 11

2.1.1 Diagrama UML de Casos de Uso 12

2.2 Requisitos no funcionales 15

2.3 Requisitos funcionales 16

2.3.1 Historias de usuario 16

2.3.1.1 Especificación de las historias de usuario 17

3. Diseño 27

3.1 Diagrama de Clases 27

3.2 Diagrama de Entidad-Relación 28

3.3 Diagrama de Arquitectura 29

3.3.1 Capa de Seguridad 30

Tipo de concesión de credenciales de cliente 30

Acceso con credenciales de Google 31

3.3.2 Notificaciones PUSH 32

3.3.2.1 Notificaciones Web PUSH con Firebase 33

3.3.3 Rate Limit 34

3.3.4 Interfaces de la capa Controladora de la API Rest 35 3.3.5 Interfaces de Usuario de nuestra aplicación 46

3. Implementación 48

3.1 Implementación de los Endpoints 48

3.2 Capa de Seguridad 52

3.2.1 Client Credentials para nuestra API 52 3.2.2 Google Credentials en la interfaz de usuario 59

3.3 Rate Limit 62

3.4 Push Notifications 67

3.5 Interfaz de Usuario 71

(8)

5. Mejoras y evolución 83

6. Conclusiones 84

7. Glosario 85

8. Bibliografía 86

9. Anexos 87

(9)

(10)

1. Introducción

Introducción a la creación de una infraestructura de API en tiempo real

Reflejando el auge de las aplicaciones basadas en API, el tiempo real se está convirtiendo en una fuerza emergente en el desarrollo de aplicaciones modernas. Está impulsando la mensajería instantánea, las transmisiones en vivo, la geolocalización, el big data y las transmisiones sociales. Pero, ¿qué es el tiempo real y qué significa realmente? ¿Qué tipos de software y tecnología están impulsando esta industria?

Sumerjámonos en ello.

¿Qué es tiempo real?

El tiempo real podría definirse en un sentido temporal más relativo. Podría significar que un cambio en A se sincroniza con un cambio en B. O podría significar que un cambio en A desencadena inmediatamente un cambio en B. O bien... podría significar que A le dice a B que algo cambió, pero B no hace nada. O... ¿significa que A les dice a todos que algo cambió, pero no le importa quién escuche?

Profundicemos un poco más. En tiempo real no significa necesariamente que algo se actualice al instante (de hecho, no existe una definición singular de "al instante"). Entonces, no nos centramos en el efecto, sino en el mecanismo. El tiempo real se trata de enviar datos lo más rápido posible: es una comunicación automatizada, sincrónica y bidireccional entre puntos finales a una velocidad de unos pocos cientos de milisegundos.

● Síncrono significa que ambos puntos finales tienen acceso a los datos al mismo tiempo.

● Bidireccional significa que los datos se pueden enviar en cualquier dirección.

● Los puntos finales son emisores o receptores de datos (teléfono, tablet, servidor).

● Unos pocos cientos de milisegundos es una métrica un tanto arbitraria, ya que los datos no se pueden entregar al instante, pero se alinea más estrechamente con lo que los humanos perciben como tiempo real.

Con esta definición y sus advertencias en mente, exploremos el concepto de enviar datos. Centrándonos en dos puntos base

(11)

Comunicaciones asíncronas

Comenzaremos contrastando el envío de datos con la "solicitud-respuesta"

(request-response). La solicitud-respuesta es la forma más fundamental en que se comunican los sistemas informáticos. La computadora A envía una solicitud de algo a la computadora B y la computadora B responde con una respuesta.

En otras palabras, puede abrir un navegador y escribir "reddit.com". El navegador envía una solicitud a los servidores de Reddit y responden con la página web.

En un modelo de envío de datos, los datos se envían al dispositivo de un usuario en lugar de que el usuario los extraiga (los solicite). Por ejemplo, el correo electrónico push moderno permite a los usuarios recibir mensajes de correo electrónico sin tener que verificarlos manualmente. De manera similar, podemos examinar el impulso de datos en un sentido más continuo, en el que los datos se transmiten continuamente. Cualquiera que tenga acceso a un canal o frecuencia en particular puede recibir esos datos y decidir qué hacer con ellos.

Infraestructura en Tiempo Real como Servicio

“La infraestructura como servicio (IaaS) es una oferta estandarizada y altamente automatizada, en la que los recursos informáticos, complementados con capacidades de almacenamiento y redes, son propiedad de un proveedor de servicios y los alojan, y se ofrecen a los clientes bajo demanda. Los clientes pueden auto aprovisionarse de esta infraestructura mediante una interfaz gráfica de usuario basada en web que sirve como consola de administración de operaciones de TI para el entorno general. El acceso API a la infraestructura también se puede ofrecer como una opción”.

(12)

A menudo usamos PaaS (plataforma como servicio) y SaaS (software como servicio), entonces, ¿en qué se diferencian de IaaS?

● Infraestructura como servicio (IaaS): el hardware lo proporciona un proveedor externo y lo administra usted.

● Plataforma como servicio (PaaS): tanto el hardware como la capa de su sistema operativo se administran por usted.

● Software como servicio (SaaS): se proporciona una capa de aplicación para la plataforma y la infraestructura (que se administra por usted).

Para potenciar el tiempo real, las aplicaciones requieren un sistema cuidadosamente diseñado de servidores, API, balanceadores de carga, etc. En lugar de construir estos sistemas internamente, las organizaciones encuentran que es más rentable y eficiente en recursos comprar gran parte de esta infraestructura sistémica y luego conducirla internamente. Estos sistemas, por lo tanto, no son solo IaaS, sino que generalmente brindan una plataforma y una capa de software para ayudar con la administración. En términos fundamentales, su beneficio principal es que proporcionan una infraestructura en tiempo real, ya sea que la aloje internamente o confíe en una instancia administrada.

Todo se reduce a la simple verdad de que el tiempo real es difícil por varias razones:

● Demanda de tiempo de actividad del cliente: los clientes que dependen de las actualizaciones en tiempo real se darán cuenta de inmediato cuando su red no esté funcionando.

● Escalabilidad horizontal: debe poder manejar cargas volátiles y masivas en su sistema o correr el riesgo de tiempo de inactividad. Por lo general, esto se logra mediante una escalabilidad horizontal inteligente y sistemas que pueden administrar millones de conexiones simultáneas.

● Complejidad arquitectónica: mantener un sistema en tiempo real con buen rendimiento no solo es complejo, sino que requiere una amplia experiencia y conocimientos. Esto es costoso de comprar, especialmente en el mercado de ingeniería de alta demanda actual.

● Contingencias: inevitablemente, su sistema experimentará algún tiempo de inactividad, ya sea debido a un pico de carga anticipado o a una función recientemente lanzada. Por lo tanto, es importante contar con múltiples contingencias de tiempo de actividad para asegurarse de que el sistema sepa qué hacer, en caso de que su mecanismo principal en tiempo real no funcione.

● Cola: cuando envía una gran cantidad de datos, es probable que necesite un mecanismo de cola intermedio para asegurarse de que sus procesos de back-end no se sobrecarguen con una mayor carga de mensajes.

(13)

IaaS de aplicaciones en tiempo real

La infraestructura de aplicaciones en tiempo real envía datos a navegadores y clientes. Por lo general, utiliza mensajes de publicación/suscripción, webhooks y/o websockets, y es independiente de la API principal de una aplicación o servicio. Estas soluciones son las mejores para las organizaciones que buscan mensajería en tiempo real sin necesidad de crear sus propias API en tiempo real.

Estos sistemas también tienen herramientas de administración de software/plataforma mejor construidas además de sus ofertas de infraestructura. Por ejemplo, los principales proveedores tienen herramientas de configuración integradas como controles de acceso, delegación de eventos, herramientas de depuración y configuración de canales.

Beneficios de la aplicación en tiempo real IaaS

● Velocidad: típicamente diseñada explícitamente para entregar datos con latencias bajas a los dispositivos de los usuarios finales, incluidos teléfonos inteligentes, tabletas, navegadores y computadoras portátiles.

● Múltiples SDK para una integración más sencilla.

● Utiliza plataformas de entrega de datos en tiempo real distribuidas globalmente.

● Adaptadores de múltiples protocolos.

● Bien probado en entornos de producción.

● Mantiene la configuración interna al mínimo.

(14)

1.1 Objetivos del Trabajo

Según lo visto en el apartado anterior, el objetivo principal de nuestro proyecto va a consistir en el desarrollo de toda la arquitectura e infraestructura mínima necesaria para el desarrollo de una API en tiempo real. Para ello nos fijaremos los siguientes objetivos:

1. Creación de un API de publicación

a. Siguiendo las directrices OpenAPI Specification[1]

b. Seguridad de acceso siguiendo el estándar de autenticación OAuth 2.0 [2]

c. Asegurar el número de peticiones que puede recibir nuestro API para no sobrecargar el sistema y defender frente ataques.

d. Seguir un enfoque de arquitectura hexagonal 2. Mensajería Publish/Service

a. Habilitar un canal de suscripción para notificaciones

b. Integrar con proveedor de notificaciones a suscriptores (En nuestro caso usaremos Firebase [3]

3. Interfaz de usuario

a. Generar una interfaz mínima de visualización del contenido b. Garantizar acceso securizado para nuestros usuarios c. Habilitar subscripción a nuestro sistema de mensajería

1.1.1 Funcionalidades generales

Para justificar el desarrollo de nuestro proyecto expondremos la siguiente funcionalidad.

Actualmente la venta de videojuegos de tiendas online es uno de los negocios más en auge a nivel mundial. Los compradores de videojuegos sienten la necesidad de unificar en una única plataforma todos los videojuegos de las distintas tiendas online. Además de poder subscribirse a determinadas categorías de videojuegos para ser notificados cuando se publica un nuevo videojuego de la categoría favorita del usuario.

Como tienda online quiero poder publicar mis videojuegos en “My Life Is A Game”, portal web donde los usuarios se conectan para ver el contenido de distintas tiendas de videojuegos siguiendo el estándar de autenticación Oauth para garantizar la seguridad de mis publicaciones.

Como tienda online quiero poder publicar, editar y eliminar videojuegos en el portal vía API.

(15)

Como tienda online quiero que la documentación entregada sea legible y siga los estándares de OpenAPI Specification.

Como usuario comprador de videojuegos quiero poder conectarme a “My Life Is A Game”, portal web donde puedo encontrar todos los videojuegos de las principales tiendas online de videojuegos.

Como usuario para acceder tendré que poder acceder con mi cuenta de gmail.

Como usuario tendré la posibilidad de ver todos los videojuegos publicados por las tiendas y la posibilidad de filtrar por las distintas categorías de

videojuegos.

Como usuario podré inscribirme a una categoría concreta para ser notificado cuando se publique un nuevo juego de esa categoría por cualquiera de las tiendas.

Yo, como administrador, quiero poder dar de alta nuevas tiendas online para poder publicar vía API en el portal.

Los objetivos principales que sigue nuestra propuesta de TFG será la siguiente:

1. Creación de un API REST a la que las distintas tiendas online puedan integrarse de forma sencilla y segura.

2. Creación de una interfaz gráfica en la que puedan navegar los siguientes perfiles:

a. Un usuario que pueda navegar por los videojuegos publicados en la plataforma y suscribirse a notificaciones de nuevas categorías

1.1.2 Stack Tecnológico

● JDK 11

● IDE: IntelliJ IDEA Ultimate

● Framework Spring-Boot (servidor tomcat embebido, spring-data, spring-security, flyway)

● Apache Maven como herramienta de software para la gestión y construcción de proyectos Java

● MySQL como gestor de base de datos

● Redis [4] como sistema de caché para nuestra política de peticiones

(16)

● Apache Kafka y Firebase para nuestras notificaciones PUSH

● Swagger para documentar nuestra API

● Git como software de control de versiones, junto con GitHub como gestor de repositorios.

● React [5] para construir nuestra interfaz gráfica

● Docker para ayudarnos a desplegar parte de nuestra infraestructura

El 90% de nuestro lenguaje de programación será en Java. Para justificar nuestra elección podemos fijarnos en índice TIOBE de 2022 donde Java sigue siendo uno de los lenguajes líderes en el sector tecnológico.

Índice TIOBE 2022 [6]

1.2 Enfoque y método seguido

Para el desarrollo de nuestro TFG hemos querido usar todos los conocimientos adquiridos a lo largo del Grado y plasmar este conocimiento en el desarrollo de un producto nuevo usando las tecnologías y metodologías más actuales. De esta forma pondremos en práctica todo lo aprendido a lo largo de estos años y nos servirá de cara a nuestro enfoque profesional.

Hemos decidido seguir un enfoque iterativo basado en la metodología ágil SCRUM, basando nuestros entregables en pequeños sprints para marcarnos objetivos reales. El objetivo final es la entrega de un MVP (mínimo producto viable) que nos garantizara la entrega de los productos mencionados en el apartado -1.2 Objetivos del Trabajo - centrándonos principalmente en las funcionalidades de API que es donde radica la complejidad de este proyecto.

(17)

1.3 Planificación del Trabajo

Para la planificación del trabajo se ha seguido la siguiente planificación detallada en el esquema de Gant.

1.4 Breve sumario de productos obtenidos Plan de Trabajo

Definición de los requisitos funcionales, el stack tecnológico elegido, el objetivo del proyecto y la planificación

Análisis y Diseño del sistema

Documento de análisis y diseño del proyecto a desarrollar, con la especificación de los casos de uso y su alcance. Además, se incluyen los diagramas de arquitectura y de clases.

(18)

Implementación

Implementación completamente funcional en cuanto a los requisitos especificados para este trabajo. Además, se genera un manual de instalación y toda la documentación de las pruebas del sistema.

Presentación y Memoria

Finalmente, se obtendrá el presente documento completo junto con una presentación del trabajo realizado en diapositivas y un video como presentación virtual del trabajo desarrollado.

1.5 Breve descripción de los otros capítulos de la memoria

- Análisis: En este apartado se analizará los requisitos y funcionalidades necesarias para resolver el problema planteado.

- Diseño: Diseño elegido para implementar el trabajo a desarrollar, todos los componentes necesarios para cubrir los requerimientos, estudiaré el punto de vista de la información y la arquitectura del sistema.

- Implementación: En este capítulo concretará a más bajo nivel como se ha llevado a cabo la implementación del proyecto en las diferentes capas, detallará los inconvenientes y sensaciones a lo largo del desarrollo del trabajo y por último indicará las herramientas utilizadas.

- Pruebas: Este capítulo sirve como introducción y planteamiento del juego de pruebas llevado a cabo, que posteriormente se desarrolla con más detalle en el Anexo de Tests unitarios y pruebas del sistema.

- Mejoras y Evolución del producto: Todas las mejoras posibles y soluciones que me hubiera gustado abordar pero que por la limitación temporal de este trabajo, he tenido que dejar fuera del alcance del mismo.

- Conclusiones: En este apartado, se comentará mi perspectiva sobre todo el proceso de elaboración de este trabajo

(19)

2. Análisis

Basándonos en los objetivos definidos en los apartados anteriores sobre el proyecto que vamos a desarrollar, pasamos a identificar los roles que van a estar implicados en nuestro proyecto, los requisitos a cumplir, los módulos implicados y la arquitectura de nuestro sistema.

2.1 Roles

Vamos a contemplar tres roles en nuestro sistema que detallamos a continuación:

→Tienda: Podrá acceder a los recursos públicos y asociados a su rol. Los recursos asociados serán a peticiones POST, PUT y DELETE sobre sus datos y anuncios de videojuegos.

→ Usuario: Podrá hacer uso de los recursos públicos del API. Podrá visualizar el contenido publicado por las empresas y suscribirse a una categoría para recibir notificaciones.

→Administrador: Podrá acceder a todos los recursos públicos, podrá acceder a recursos protegidos asociados a su rol, tales como peticiones POST, PUT y DELETE sobre categorías y habilidades y PUT y DELETE sobre empresas y profesionales

(20)

2.1.1 Diagrama UML de Casos de Uso

En el apartado 2.3 se describe en más detalle las historias de usuario

Casos de Uso de las Tiendas

(21)

Casos de Uso de los Usuarios

(22)

Casos de Uso del Administrador

(23)

2.2 Requisitos no funcionales

El desarrollo del proyecto seguirá una metodología ágil de tipo SCRUM buscando los siguientes objetivos:

- La auto organización, porque Scrum está muy enfocado a ser capaz de autogestionarse, de saber llevar la carga de trabajo en todo momento, de que se tenga el control del tiempo, etc. Por todo eso debido al tiempo para el desarrollo de nuestro proyecto, marcaremos ritmos y el desarrollo en progresivo, ya que se va avanzando a medida que va pasando el tiempo y vamos adquiriendo madurez y se procede a un valor incremental.

- La priorización, debido a que existen prioridades y se establecen criterios para saber qué trabajos son más importantes y son los primeros que hay que desarrollar. Scrum es una metodología muy abierta, flexible y que se adapta a las necesidades de los clientes en cada momento. Si aparece algo urgente, se le puede asignar una prioridad y ponerse a trabajar de forma inmediata.

● Nuestra aplicación seguirá los principios de la arquitectura REST:

Verbs Methods

GET, POST, PUT and DELETE Recursos

● Aceptar y responder con JSON

● Usar nombres en lugar de verbos en el path de los endpoints

● Nombrar colecciones con nombres en plural

○ GET /v1/shops

○ GET /v1/shops/1234

● Recursos anidados para jerarquía de objetos

○ GET /v1/shops/1234/categories

(24)

● Manejar errores de manera eficiente y devolver códigos de errores estándares de HTTP

● El body de las peticiones será en formato JSON para transferir la información.

● Todas las peticiones para las empresas deben estar autenticadas usando Oauth 2.0 para securizar el acceso.

● Los tiempos de respuesta deben ser razonables.

● Se debe evitar la sobrecarga del API usando un límite de peticiones para lo que se implementará un sistema de caché usando Redish.

● Se usará MySQL como gestor de base de datos.

2.3 Requisitos funcionales

Para el servicio que queremos ofrecer estableceremos los requisitos funcionales que se muestran a continuación siguiendo las siguientes categorías:

→ Datos de las tiendas: Las tiendas podrán dar de alta sus datos en el sistema y gestionar su perfil. También podrán gestionar la publicación de sus videojuegos dentro de una de las categorías disponibles. (Tienda)

→ Datos de los usuarios: los usuarios podrán acceder al listado de los videojuegos publicados, pudiendo filtrar por categorías de videojuegos y subscribirse a una categoría para ser notificado siempre que se publique un videojuego nuevo perteneciente a esa categoría. (Usuario)

→Datos de administración: El administrador podrá llevar a cabo el alta y desactivación de las tiendas para acceder al API de publicación. A su vez podrá gestionar las distintas categorías de videojuegos.

2.3.1 Historias de usuario

Historias de usuario

US - 001 Como tienda quiero poder dar de alta mis datos profesionales y estar visible en la plataforma

US - 002 Como tienda quiero poder dar de alta mis videojuegos para que sean visibles para el usuario

US - 003 Como tienda quiero saber las categorías de videojuegos disponibles para poder asignar una categoría a mis videojuegos para el usuario

US - 004 Como usuario quiero poder registrarme en el sistema usando mi cuenta de

(25)

Google

US - 005 Como usuario quiero poder ver el listado de todos los videojuegos disponibles

US - 006 Como usuario quiero poder filtrar por categoría todos los videojuegos disponibles

US - 007 Como usuario quiero poder buscar por nombre un videojuego US - 008 Como usuario quiero poder suscribirme a una categoría concreta de

videojuegos para recibir notificaciones sobre esa categoría cada vez que se publique un nuevo videojuego

US - 009 Como administrador quiero poder dar de alta credenciales para nuevas tiendas

US - 010 Como administrador quiero poder consultar todas las tiendas dadas de alta en el sistema

US - 011 Como administrador quiero poder desactivar tiendas dando de baja todos los videojuegos publicados por la tienda desactivada

US - 012 Como administrador quiero poder crear nuevas categorías para los videojuegos publicados

US - 0113 Como administrador quiero poder consultar todas las categorías disponibles

2.3.1.1 Especificación de las historias de usuario

DETALLE HISTORIA 001

US - 001 Como tienda quiero poder dar de alta mis datos profesionales y estar visible en la plataforma

Criterios de aceptación

Dado una tienda que accede al API en una aplicación cliente

Cuando la aplicación realiza la petición al endpoint del servicio REST adecuado con una request válida que contiene los parámetros relativos a los datos de la tienda

Entonces el cliente recibe un código de estado 201 (creado) Y en la respuesta se recibe la siguiente información: shopId API

POST /shop

(26)

RESPONSE STATUS

201 Created

RESPONSE shopId

ALTERNATIVE 400 Bad Request (error en parámetros de entrada) 401 Unahorized (si no está logado o no tiene el tokenId) 500 Internal Server Error

PUT /shop/{shopId}

RESPONSE STATUS

200 OK

RESPONSE shopId

US - 002 Como tienda quiero poder dar de alta mis videojuegos para que sean visibles para el usuario

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a los datos de un videojuego

Entonces el cliente recibe un código de estado 201 (creado) Y en la respuesta se recibe la siguiente información: videogameId API

POST /shops/{shopId}/videogames RESPONSE

STATUS

201 Created

RESPONSE videogameId

ALTERNATIVE 400 Bad Request (error en parámetros de entrada)

(27)

401 Unahorized (si no está logado o no tiene el tokenId) 500 Internal Server Error

PUT /shops/{shopId}/videogames/{videogameId}

RESPONSE STATUS

200 OK

DELETE /shops/{shopId}/videogames/{videogameId}

RESPONSE STATUS

200 OK

US - 003 Como tienda quiero saber las categorías de videojuegos disponibles para poder asignar una categoría a mis videojuegos para el usuario

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a los datos de la tienda

Entonces el cliente recibe un código de estado 200 (OK)

Y en la respuesta se recibe la siguiente información: listado de todas las categorías disponibles API

GET /shops/{shopId}/categories RESPONSE

STATUS

200 OK

(28)

RESPONSE categories list

US - 004 Como usuario quiero poder registrarme en el sistema usando mi cuenta de Google

Dado un usuario que accede al API en una aplicación cliente usando Google

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a los datos de la tienda

Entonces el cliente recibe un código de estado 200 (OK) Y en la respuesta se recibe la siguiente información: userId API

POST /user/login

RESPONSE STATUS

200 OK

RESPONSE no response

POST /user/logout

RESPONSE STATUS

200 OK

RESPONSE no response

(29)

US - 005 Como usuario quiero poder ver el listado de todos los videojuegos disponibles

Dado un usuario que accede al API en una aplicación cliente

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos para poder ver todos los videojuegos Entonces el cliente recibe un código de estado 200 (OK)

Y en la respuesta se recibe la siguiente información: listado de todos los videojuegos API

GET /users/{userId}/videogames RESPONSE

STATUS

200 OK

RESPONSE videogames list

GET /users/{userId}/videogames/{videogameId}

RESPONSE STATUS

200 OK

RESPONSE videogame

(30)

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a la categoría de los videojuegos Entonces el cliente recibe un código de estado 200 (OK)

Y en la respuesta se recibe la siguiente información: listado de todos los videojuegos por categoría

API

GET /users/{userId}/videogames/categories/{categoryId}

RESPONSE STATUS

200 OK

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos al nombre de los videojuegos Entonces el cliente recibe un código de estado 200 (OK)

Y en la respuesta se recibe la siguiente información: listado de todos los videojuegos por nombre

API

GET /users/{userId}/videogames/categories/{search}

RESPONSE STATUS

200 OK

(31)

US - 008 Como usuario quiero poder suscribirme a una categoría concreta de videojuegos para recibir notificaciones sobre esa categoría

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a la suscripción de una categoría Entonces el cliente recibe un código de estado 202 (aceptado)

Y en la respuesta se recibe la siguiente información: categoryId API

POST /users/{userId}/videogames/categories/{categoryId}/subscribe RESPONSE

STATUS

200 OK

RESPONSE categoryId

US - 009 Como administrador quiero poder dar de alta credenciales para nuevas tiendas

Dado un administrador que accede al API en una aplicación cliente

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una

(32)

request válida que contiene los parámetros relativos a los credenciales de una tienda Entonces el cliente recibe un código de estado 201 (creado)

Y en la respuesta se recibe la siguiente información: tokenid y clientId API

POST /admins/shops

RESPONSE STATUS

201 Created

RESPONSE tokenId y clientId

ALTERNATIVE

400 Bad Request (error en parámetros de entrada) 401 Unahorized (si no está logado o no tiene el tokenId) 500 Internal Server Error

US - 010 Como administrador quiero poder consultar todas las tiendas dadas de alta en el sistema

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida para obtener todas las tiendas

Entonces el cliente recibe un código de estado 200 (ok) Y en la respuesta se recibe la siguiente información: shops list API

POST /admins/shops

RESPONSE STATUS

200 OK

RESPONSE shops list

ALTERNATIVE

(33)

US - 011 Como administrador quiero poder desactivar tiendas dando de baja todos los videojuegos publicados por la tienda desactivada

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a la desactivación de una tienda Entonces el cliente recibe un código de estado 200 (OK)

Y en la respuesta se recibe la siguiente información: shopId API

DELETE /admins/shops/{shopId}

RESPONSE STATUS

200 OK

RESPONSE shopId

ALTERNATIVE

US - 012 Como administrador quiero poder crear nuevas categorías para que los videojuegos publicados

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a la creación de una categoría Entonces el cliente recibe un código de estado 201 (creado)

Y en la respuesta se recibe la siguiente información: categoryId API

POST /admins/categories

(34)

RESPONSE STATUS

201 Created

RESPONSE categoryId

ALTERNATIVE

US - 013 Como administrador quiero poder consultar todas las categorías disponibles

Cuando la aplicación realiza la petición al end point del servicio REST adecuado con una request válida que contiene los parámetros relativos a la creación de una categoría Entonces el cliente recibe un código de estado 200 (OK)

Y en la respuesta se recibe la siguiente información: category list API

GET /admins/categories

RESPONSE STATUS

201 Created

RESPONSE category list

ALTERNATIVE

(35)

3. Diseño

3.1 Diagrama de Clases

Siguiendo los requisitos planteados en la sección anterior, el siguiente diagrama de clases desde el punto de vista de la información con los que trabajará nuestro sistema

Detalles de las clases

→ Shops: Detalles de las tiendas de videojuegos, las cuales tendrán que autenticarse mediante un clientId y clientSecret de Oauth. Además guardaremos su nombre,

descripción, email de contacto y logo de la tienda.

→ User: Usuarios que acceden a nuestro sistema, tienen que autenticar mediante un clientId y clientSecret autogestionado por Google con Oauth

(36)

→ Admin: El administrador del sistema, tendrá que autenticarse mediante un clientId y clientSecret de Oauth

→ Games: Detalles de los juegos que publican las tiendas. Se guardará el nombre, descripción, una imágen, el precio y la fecha de venta del videojuego

→ Categories: Las categorías a las que puede pertenecer un videojuego y a la que se pueden suscribir los usuarios. Guardaremos el nombre y descripción de la categoría.

3.2 Diagrama de Entidad-Relación

A continuación estableceremos el diagrama de entidades relacionales que persistirán en nuestra base de datos, de forma orientada a nuestro SGBD elegido que en nuestro caso será MySQL.

(37)

3.3 Diagrama de Arquitectura

Nuestro sistema seguirá un enfoque de Arquitectura Hexagonal [7]. Tiene como principal motivación separar nuestra aplicación en distintas capas o regiones con su propia responsabilidad. De esta manera conseguimos desacoplar capas de nuestra aplicación permitiendo que evolucionen de manera aislada. Además, tener el sistema separado por responsabilidades nos facilitará la reutilización

(38)

3.3.1 Capa de Seguridad

Para nuestra capa de seguridad vamos a implementar dos niveles de autenticación. El accesos a nuestra API estará securizado siguiendo Oauth client crendentials grant type y para el acceso a nuestra interfaz web se usará el mismo protocolo pero accediendo mediante una cuenta de Google.

Tipo de concesión de credenciales de cliente

La concesión de credenciales de cliente de OAuth 2.0 especificada en RFC 6749 [8], a veces denominada OAuth de dos patas, para acceder a los recursos alojados en la web mediante la identidad de una aplicación. Este tipo de concesión se usa

comúnmente para interacciones de servidor a servidor que deben ejecutarse en segundo plano, sin interacción inmediata con un usuario. Estos tipos de aplicaciones a menudo se denominan demonios o cuentas de servicio.

El flujo de otorgamiento de credenciales de cliente de OAuth 2.0 permite que un servicio web (cliente confidencial) use sus propias credenciales, en lugar de hacerse pasar por un usuario, para autenticarse al llamar a otro servicio web.

En el flujo de credenciales del cliente, un administrador concede los permisos directamente a la propia aplicación. Cuando la aplicación presenta un token a un recurso, el recurso exige que la propia aplicación tenga autorización para realizar una acción, ya que no hay ningún usuario involucrado en la autenticación.

(39)

Una de las ventajas además que nos ofrece Oauth es la posibilidad de asignar roles a nuestros usuarios acreditados. En nuestro caso concreto vamos a tener tres tipos de roles para poder acceder a los recursos de nuestros endpoints:

● ADMIN: Podrá acceder a todos los recursos de administración: crear credenciales, dar de alta/baja tiendas, etc.

● SHOPS: Podrá acceder a todos los recursos necesarios para las tiendas: crear, modificar y borrar videojuegos; editar su perfil de tienda.

● USERS: Podrá acceder a los recursos necesarios para los usuarios: listar videojuegos y subscribirse a una categoría.

Acceso con credenciales de Google

Los usuarios tendrán una interfaz web en la que podrán acceder con sus credenciales de Google.

La secuencia de autorización comienza cuando nuestra aplicación redirecciona un navegador a una URL de Google. La URL incluye parámetros de búsqueda que indican el tipo de acceso que se solicita. Google se encarga de la autenticación, la selección de las sesiones y el consentimiento del usuario. El resultado es un código de autorización que la aplicación puede intercambiar por un token de acceso y un token de actualización.

Nuestra aplicación debe almacenar el token de actualización para usarlo en el futuro y usarlo para acceder a una API de Google. Una vez que el token de acceso caduca, la aplicación usa el token de actualización para obtener uno nuevo.

(40)

3.3.2 Notificaciones PUSH

Las notificaciones web push se basan en dos estándares web: API de notificación y API push (que a su vez usa ServiceWorker).

Suscribirse a notificaciones push

● El servidor comparte su clave pública con el navegador.

● El navegador utiliza la clave pública para suscribirse a un servicio push (cada navegador tiene la suya propia)

● El servicio push devuelve una suscripción con una URL de punto final única que se puede usar para enviar mensajes push

● La suscripción se guarda en el servidor.

Envío de notificaciones automáticas

● El servidor firma un encabezado de autorización con su clave privada

● El servidor envía el mensaje a la URL única del punto final

● El servidor push descifra el encabezado de autenticación

● El servidor push envía el mensaje al dispositivo/navegador

(41)

3.3.2.1 Notificaciones Web PUSH con Firebase

Es una tecnología que ofrecen los navegadores modernos, que permite enviar mensajes a los usuarios que visitaron en algún momento nuestra página web, aún si al momento del envío el usuario no está con la página abierta.

Funciona similar a las Push Notifications en las App, pero enviando los mensajes a los navegadores de nuestros clientes. En el caso de PC, el navegador debe estar abierto (no tiene porque estar en nuestra página) y en el caso de Chrome para Android, el mismo no tiene siquiera que estar abierto, brindando una herramienta muy similar a la de las Apps.

Las Web Push Notifications brindan un poderoso canal de comunicación con nuestros clientes, notificándolos en tiempo real sobre distintos asuntos, eventos, promociones, productos, etc., y derivándolos en forma sencilla a nuestra página web y/o WebApp.

Para poder enviar Web Push Notifications es necesario contar con un servidor de notificaciones, que pueda conectarse a Firebase o Google Cloud Messaging Service, quien finalmente entregará el mensaje al navegador del usuario, tal como se presenta en la siguiente figura:

(42)

3.3.3 Rate Limit

La limitación de peticiones es importante para prevenir ataques maliciosos en nuestra API.

La limitación de peticiones se aplica a la cantidad de llamadas que un usuario puede realizar a una API dentro de un marco de tiempo establecido. Esto se usa para ayudar a controlar la carga que se pone en el sistema.

La limitación de velocidad ayuda a evitar que un usuario agote los recursos del sistema. Sin limitación de peticiones, es más fácil que una parte malintencionada abrume el sistema. Esto se hace cuando el sistema se inunda con solicitudes de información, lo que consume memoria, almacenamiento y capacidad de red.

Una API que utiliza la limitación de llamadas puede limitar a los clientes que intentan realizar demasiadas llamadas o bloquearlos temporalmente por completo. Los usuarios que han sido limitados pueden ver sus solicitudes denegadas o ralentizadas durante un tiempo determinado. Esto permitirá que se cumplan las solicitudes legítimas sin ralentizar toda la aplicación.

La API responde con el código de estado HTTP 429 Too Many Requests (Demasiadas solicitudes) cuando una solicitud tiene una velocidad limitada o acelerada.

En nuestro caso concreto, usando Rate Limiter podemos hacer cumplir nuestras políticas de la siguiente manera:

(43)

● Limitaremos las peticiones que pueden realizar las tiendas a 2 peticiones por minuto. Esto ayuda a minimizar el spam o la creación de cuentas maliciosas, y la denegación de servicio (DoS) y la denegación de servicio distribuida (DDoS)

● Limitaremos a los usuarios a 10 peticiones por segundo para garantizar una búsqueda fluida de los videojuegos, pero para garantizar la seguridad frente a un ataque

Para limitar el número de peticiones, se ha implementado un sistema de caches usando Redis en las que guardaremos la IP del consumidor de nuestra API y un contador con el número de peticiones y el TTL (time to live, o tiempo de expiración) definido para cada recurso como comentamos anteriormente. De esta forma si por ejemplo tenemos un límite de 2 peticiones por minuto para un recurso (endpoint), nuestra caché no se refrescará hasta que pase un minuto sin recibir peticiones para permitir de nuevo el acceso al recurso.

3.3.4 Interfaces de la capa Controladora de la API Rest

Para la definición de la capa de control de nuestra API Rest hemos seguido el

estándar de OpenAPI Specification que nos ayuda a definir nuestras interfaces de una manera agnóstica del lenguaje.

(44)

Podemos observar que nuestras interfaces quedan definidas en tres servicios cuyos detalles pasamos a mostrar a continuación

(45)

Shops

Recursos disponibles para las tiendas

(46)

(47)

Users

Recursos disponibles para los usuarios

(48)

(49)

(50)

(51)

Admin

Recursos disponibles para el administrador

(52)

(53)

(54)

3.3.5 Interfaces de Usuario de nuestra aplicación

El usuario podrá acceder en la aplicación usando una cuenta de Google. Una vez logado, podrá navegar por la página para visualizar los videojuegos publicados, pudiendo usar un buscador o filtrando por categorías. Además podrá suscribirse a una categoría para que si se publica nuevo contenido sea notificado.

A continuación se detalla un prototipo de los distintos estados de navegación 1. Pantalla de acceso del usuario:

(55)

2. Pantalla de interacción del usuario: se mantendrá la navegación del usuario en una sola vista. En ella se listan por defecto los videojuegos más recientes. El usuario puede usar el buscador para buscar videojuegos que coincidan con el texto indicado, filtrar por categorías y en caso de no estar suscrito a esa categoría pulsar el botón de suscribirse.

(56)

3. Implementación

A lo largo del siguiente apartado se describirán los puntos claves de nuestro proyecto a nivel de implementación, indicando el código de los puntos más relevantes de este.

3.1 Implementación de los Endpoints

Tendremos tres clases Controllers para nuestros tres actores/consumidores principales(Administrador, Tiendas y Usuarios) , con acceso a los distintos recursos ofrecidos para cada uno de ellos.

Nuestro servicio de API estará implementado en el artefacto:

mylifeisagame-api

(57)

AdminRESTController

(58)

ShopsRESTController

(59)

UsersRESTController

(60)

3.2 Capa de Seguridad

Como comentamos en la parte de diseño, tendremos dos capas de seguridad, una a nivel de API y otra a nivel de interfaz de usuario. Ambas capas estarán basadas en client-credentials, la única distinción será que para las tiendas y administración usarán credenciales para poder usar los endpoints de nuestra API, mientras que para los usuarios se habilitará la posibilidad de acceder usando las credenciales de una cuenta de Google.

3.2.1 Client Credentials para nuestra API

Para la capa de seguridad de nuestra api tenemos un artefacto o servicio independiente que se encargará de ello: authserver

Spring-boot nos facilita todas las clases necesarias para añadir nuestra capa de seguridad con Oauth 2.0 importando las siguientes dependencias

Para crear una clase de seguridad personalizada, necesitamos usar

@EnableWebSecurity y extender la clase con @WebSecurityConfigurerAdapter para que podamos redefinir algunos de los métodos proporcionados

(61)

(62)

Spring Security nos fuerza a hashear las contraseñas para que no se guarden en texto plano. Para ello vamos a usar la clase MD5PasswordEncoder para guardar todas nuestras credenciales en MD5[9]

Para crear nuestro token de acceso y refrescar tendremos la clase CustomTokenService que extiende de DefaultTokenServices, que nos garantizará por defecto que el token de acceso seguirá vigente durante 12 horas (para un caso real es mejor bajar la tasa de refresco a cada 5 minutos por ejemplo para garantizar mayor seguridad, pero para nuestro caso de estudio por facilitar las cosas hemos decidido usar el de defecto)

(63)

Por último, Oauth nos obliga crearnos una clase JPA con unos campos por defecto donde guardará todos los datos necesarios para su correcto funcionamiento, entre ellos el clientId, el token de refresco y el scope (rol) del perfil .

(64)

(65)

Uso de auth-server dentro de nuestra API (mylifeisagame-api):

Spring-boot nos facilita también todas las clases necesarias para añadir nuestra capa de seguridad con Oauth 2.0 en el cliente.

Además deberemos añadir la siguiente configuración en nuestro fichero properties o yml de configuración para añadir la url del servidor de autenticación, pudiendo además indicar un usuario por defecto para acceder

(66)

Las clases más relevantes son las siguientes:

MyLifeIsAGameApplication

En nuestra clase main de spring-boot usaremos las anotaciones

“@EnableResourceServer” para habilitar nuestra capa de seguridad con oauth y “@EnableGlobalMethodSecurity(prePostEnabled = true)” para facilitarnos la gestiona de accesos a determinados recursos en función de los roles de acceso.

Si observamos en el apartado donde describimos los endpoints de nuestra API

Rest, observaremos que se usa la anotación

“@PreAuthorize("hasAuthority(XXX)")” donde “XXX” es el rol creado en Oauth para permitir acceder a recursos concretos para ese ROL

(67)

3.2.2 Google Credentials en la interfaz de usuario

Para securizar la parte de nuestra interfaz de usuario tendremos un artefacto ad hoc para ello: authserver-login

Para permitir usar las credenciales de google en nuestro proyecto deberemos crear un proyecto nuevo en la Consola de Desarrolladores de Google[10] y meter las siguientes configuraciones generadas en nuestro fichero de configuración asociadas a nuestro proyecto

Necesitaremos además de las dependencias usadas en los anteriores proyectos de spring-security las siguientes dependencias para gestionar los tokens de Google

(68)

Para poder usar las credenciales obtenidas de google usaremos la siguiente clase de configuración

(69)

Almacenaremos el estado y la uri de redirección de Google en una cookie de corta duración. La siguiente clase proporciona funcionalidad para almacenar la solicitud de autorización en cookies y recuperarla.

(70)

3.3 Rate Limit

Para implementar nuestro control de peticiones que puede recibir nuestra API vamos a usar Redis como caché para implementar un algoritmo de control.

Para ello spring-boot nos facilita también un conector de redis importando las siguientes dependencias

(71)

Para nuestro sistema de caché vamos a guardar para nuestras peticiones la ip y un contador de llamadas para cada recurso. Para ello tendremos una clase interceptadora que se llamará antes de llegar a nuestros Controllers para verificar si puede realizarse la petición o ha superado el limite, en cuyo caso devolverá un error http 409 indicando que se han realizado demasiadas llamadas.

(72)

(73)

El tiempo definido y el número de peticiones se indicará en nuestro fichero de configuración

(74)

(75)

3.4 Push Notifications

Para la publicación de notificaciones PUSH tendremos un artefacto que se encargará de consumir nuestros eventos y notificarlos: notification

Para consumir nuestros eventos vamos a usar Apache Kafka como plataforma distribuida para la transmisión de datos que permite no solo publicar, almacenar y procesar flujos de eventos de forma inmediata, sino también suscribirse a ellos.

Spring-boot nos permite la comunicación con Kafka usando las siguientes dependencias

Para consumir los eventos tendremos la siguiente clase consumidora

(76)

Que recibirá todos los videojuegos nuevos publicados en desde nuestra API

(77)

Y una clase Listener que se encargará de emitir todos los eventos nuevos

Para la emisión de notificaciones PUSH usaremos Firebase para lo cual tendremos que configurar un conector que registrando nuestra aplicación y registrarlo en las configuraciones de nuestro artefacto

(78)

Por su lado, si el cliente tiene habilitado en su navegador los permisos para recibir notificaciones se enviarán

(79)

3.5 Interfaz de Usuario

Para la interfaz de usuario se ha decido usar React, que es una librería de JavaScript que nos ayuda a crear interfaces de usuario interactivas de forma sencilla (react-app).

Nuestra interfaz de usuario no es el objetivo de este TFG, con lo que se ha realizado de una forma sencilla, y los puntos que nos interesa centrarnos únicamente es el uso para autenticarnos con los credenciales de Google y la integración con Firebase para recibir notificaciones push que pasamos a detallar.

Integración con Google

Para la integración con Google usaremos un componente que nos redirigirá a la página de google para mostrar la página de login y posteriormente contra nuestro servicio authserver-login para registrar el usuario en nuestra aplicación.

(80)

(81)

(82)

(83)

Una vez logado nos redirigirá a la página principal con el listado de videojuegos y en el lateral izquierdo los detalles de nuestra cuenta en Google con nuestro avatar, nombre y email.

(84)

Para la integración con firebase para las notificaciones push una vez suscrito a una categoría, se necesita registrar la configuración de Firebase generada anteriormente

(85)

Y tendremos una función que será encargada de mostrarnos las notificaciones cada vez que se cree un nuevo videojuego perteneciente a nuestra categoría registrada

(86)

(87)

4. Pruebas

Para el desarrollo de nuestras pruebas hemos centrado nuestros esfuerzos principalmente en nuestro servicio de API (mylifeisagame-api). Se han realizado tres niveles de test que pasamos a describir.

Test Unitarios

Se prueba toda la comunicación con desde nuestros servicios hasta el repositorio para verificar los valores esperados

(88)

Test de Integración

Para testear nuestros endpoint usaremos la @WebMvcTest que nos facilita junit para testear y mockear las peticiones a nuestros endpoints.

(89)

Test de arquitectura

Para validar que nuestro código sigue una arquitectura hexagonal hemos usado ArchUnitTest para verificarlo.

(90)

Test End To End

Se han realizado todos los test de casos reales desde que se llama al endpoint hasta que se recibe el valor esperado usando Postman[11]

(91)

5. Mejoras y evolución

El objetivo principal del proyecto se ha cumplido al 100 por ciento, que era generar la infraestructura y módulos necesarios para integrar una API en tiempo real con todos los elementos necesarios para la interacción entre servicios externos y los usuarios.

No obstante debido al escaso tiempo necesario sigue habiendo cabida a muchas mejoras aunque el esqueleto esté entero, entre ellas podemos destacar las siguientes:

● Autenticación:

○ Cambiar la generación del token para que caduque con un menor intervalo de tiempo haciendo necesario que el cliente tenga que refrescar el token de acceso para mayor seguridad

○ Para la generación de credenciales para nuestro caso de estudio hemos facilitado un endpoint que crea las credenciales directamente. Hay herramientas más adecuadas para esto, como puede ser Keycloak [12] que se integra perfectamente con Spring y nos facilita una consola de administración donde poder gestionar las credenciales y roles de acceso de nuestros usuarios

● Rate Limit:

○ Mejorar el sistema de caché para evitar mejor posibles ataques DDos. Una de las posibilidades que investigué fue usar SpiKe Interceptors para garantizar mejor los tiempos de ventana.

● Mejorar la interfaz de usuario: Al no ser el objetivo de nuestro proyecto más allá de poder visualizar la integración de nuestros componentes, visualmente es poco agradable. Mejorar tanto a nivel de estilos (hacer responsive), cómo añadir más funcionalidades que ya nos provee el API pero no se han integrado.

● Añadir integración continua:

○ Integrar nuestros artefactos a Jenkins y usar git-flow

● Monitorización: Una de las partes que creo que es imprescindible es poder analizar las peticiones recibidas, para ello necesitamos alguna sistema de monitorización como Grafana [13]

● Escalar en distintas máquinas gestionadas por algún balanceador de carga como Nginx [14]