# Comparativa Back

A continuación tendremos una breve descripción de los sistemas de Tempo y Hero, donde veremos qué son, cómo están diseñados, el paradigama sobre el que nacieron y finalmente una comparativa entre ambos. Todo esto enfocado desde el punto del Back.

## Hero
La aplicación de Hero o Back sobre el que esta contruido, nació bajo el paradigma de dar cavida a la funcionalidad del negocio de prepago. Negocio el cual esta dividido en lo que se llama entidades recargadoras y el portal de agentes.
* Entidades recargadoras: Son servicios de terceros los cuales se integran directamente con el back para consumir sus servicios y poder vender las marcas de la compañía.
* El portal de Agentes: Es lo que comúnmente se conoce como Hero, pero en este caso sería solo el Frontal. Esta desarrollado por la empresa Tecalis y se integran de igual forma con el back.

Para poder dar este servicio, consta de 4 microservicios, escritos en java y desplegados sobre la suit de Google Cloud Platform (GCP), cada uno con su swagger:
* distributor-api: Microservicio encargado de orquestar las peticiones entre los diferentes microservicios.
* customers-api: Microservicio encargado de las operaciones que tienen que ver con agentes.
* catalogue-api: Microservicio encargado de las operaciones que tienen que ver con el catálogo de venta.
* multistore-api: Microservicio en el cual se albergan los recursos que no cuadran por diseño en los tres anteriores.

Además tiene una base de datos, concretamente una PosgresSql 14, actualmente deslpegada como micro en el entorno. Cuyo uso es para albergar ciertas tablas de producto/catalogo.

Todo ello alarmado y auditado a través de Prometheus y grafana. Y con LookerStudio para la visualización de los datos.

Actualmente se integra con el listado de las siguientes marcas de la compañía: MasMovil y Yoigo(A través del stack tecnológico de MasStack). Lyca, Lebara y LlamaYa(A través del stack tecnológico de Qvantel). Orange(Aunque está aun no esté disponible desde el frontal, a través del stack tecnológico de Teide). Y tiene en proceso la integración con Simyo(A través del stack tenológico de Huawei).

## Tempo

La aplicación de Tempo o Back sobre el que esta construido nació bajo el paradigma de dar cavida a la funcionalidad del negocio de prepago y de simplificar la y corregir diversos defectos que iremos viendo a lo largo de la comparativa.

La arquitectura contruida consta de:
* BFF: Back For Front, desplegado sobre el micro de sales-api. Api encargada de los procesos de venta del negocio, desde ventas de Sim hasta recargas, etc.
* Prepaid-Core: Actualmente no es un microservicio/api pero esta preparado para ello y solo es necesario darlo de alta en kubernetes (modificar un fichero y subirlo a Argo). Es la librería Core de todos los procesos y marcas del prepago actual, se usa desde el BFF y está pensado para poder ser usado por las nuevas entidades recargadoras que quieran vender nuestro prepago. Esta diseñado como un API RestFull.
* ETLs: Se diponen de 2 tipos de ETLs para la lectura y carga en nuestros sistemas, de la base de datos de tecalis fuera de nuestro entorno de GCP. Y una de ellas con la funcionalidad de adaptar y corregir los problemas detectados en su modelo de DDBB y alimentar el nuestro.
* Admin-api: Microservicio en fase de inicio con el fin de cubrir las necesidades del Admin actual de Hero. Se detallará más en la fase comparativa.
* Cache: Tiene una cache para procesos de carga un poco mas pesados como todas las operaciones que ha hecho un agent. Es una Redis desplegada en GCP.
* Base de datos: PostgresSql 18 (la última disponible).
* GC-Documents: Sistema de plantillas albergado en Google Cloud Documents, para la formación de tickets y diversos documentos que fueran necesarios y segmentados por marcas.

Todo ello alarmado y auditado a través de Prometheus y grafana. Y con LookerStudio para la visualización de los datos.

Actualmente se integra con el listado de las siguientes marcas de la compañía: MasMovil y Yoigo(A través del stack tecnológico de MasStack) .Lyca, Lebara y LlamaYa(A través del stack tecnológico de Qvantel). Orange(A través del stack tecnológico de Teide). Y tiene en proceso la integración con Simyo(A través del stack tenológico de Huawei).

## Comparativa
### Comparativa de funcionalidades:
* Actualmente Hero carece de la funcionalidad de creación y devolución de tickets desde el Back, ya que el frontal (de tecalis) es quien lo genera. (**Este caso hace que las entidades recargadoras no puedan generar un ticket sino lo hacen ellas mismas**).
* Actualmente Hero-Frontal carece de la venta de Orange a través del Back, lo hace directamente a través de Digo, ni siquiera de Teide (Stack final) y lo que le hace de no tener todos los procesos. Mientras que en ambos Back está disponible directamente contra Teide.
* Actualmente el Hero-frontal/admin genera inconsistencias con los sistemas por debajo usados, cómo por ejemplo en la asignación de una tienda a un dealer, no se baja dicha información hasta más stack. Esto con el Tempo/Admin se quiere solventar.
* Actualmente Hero tiene inconcluencias a nivel de ventas de productos (**Se pueden seleccionar tarifas, las cuales por debajo son realmente otra**).
* Actualmente Hero-Frontal se integra directamente con DISA porque no se paso dicha integración por el Back de Hero. Mientras que Tempo tiene la integración directa. (**Este caso hace que las entidades recargadoras no puedan tener operativas que impliquen DISA en Hero**).
* Actualmente Hero-Back tiene problemas a la hora de distinguir las casuisticas de error, por la política de diseño de las APIs y arquitectura, devoliendo todos los errores como 500 sin catalogar. Mientras que Tempo-back cataloga los errores en los rangos de 400 a 500 y con un código de error, lo que **permite clasificar errores y como actuar frente a ellos**, no solo desde le frontal, sino también desde los sistemas de métricas y/o terceros que se integrasen con ello.

### Comparativa en el diseño de las APIs:
El diseño de las APIs en Hero no sigue patrón RestFull, con lo que ello conlleva. Hasta el punto que el crecimiento de las mismas se hace bajo el paradigma de: "añademe este campo y que sea opcional". Lo que dificulta futuras integraciones de entidades recargadoras, por ejemplo, ya que los diversos procesos de venta tienen la posibilidad de enviar un monton de datos que no aplican para la marca o el proceso de venta.

Mientras que por el lado de Tempo, se ha trabajado en un diseño RestFull unificando necesidades de los flujos y homogeneidad en lo que necesita la petición para funcionar. De tal forma que la integración desde cero sea más sencilla.

### Comparativa en la implementación de las APIs:
Aunque ambos backs están basados en Java, la implementación en Tempo es más rápida y escalable, por el concepto de diseño anterior comentado (uso del estandar RestFull). Contribuyendo además así a un menor riesgo a la hora de modificación de flujos antiguos existentes, cuando se localiza también un error en ellos, o cambian por requisitos de negocio.

Además en cuanto a estandares de calidad de código, tempo, al ser más reciente ha tenido en cuenta nuevos estandares haciendo también su código más limpio y legible para desarrolladores y agentes de IA.

### Comparativa en el diseño de la DDBB:
Se ha visto que la base de datos directamente implementada por Tecalis y que se usa de forma directa desde el frontal de Hero (Los frontales nunca deben acceder a la DDBB de forma directa). No escalan, es decir: se ha visto que por ejemplo que la modificación de los agents, generan nuevas entradas en vez de modificar las existentes (creando además en esos procesos inconsistencias en otros sistemas como el anteriormente nombrado entre MasDealers y dicha DDBB).

Esto se quiere controlar con el nuevo diseño de DDBB y además con el micro de admin-tempo-api que se está desarrollando.

## Ventajas de Tempo frente a Hero:
Por todo lo anterior comentado, las ventajas de Tempo frente a Hero a nivel de back son:
* El frontal carece de lógica que no sea propia de un frontal, cómo por ejemplo la creación de tickets, la gestión de tiendas, agents, etc. La integración directa con CRMs que no le corresponden, y se centra solo en su BFF (No necesita entender de todos los stacks, solo de su BFF). Tampoco se conecta a una base de datos propia y agena al GCP de la compañía, para la gestión incompleta de sus usuarios.
* La integración desde un frontal o una entidad recargadora es más simple e intuitiva al seguir los estandares de la comunidad.
* Tiene clasificación de errores.
* Menor riesgo a la hora de modificación de flujos antiguos existentes, cuando se localiza también un error en ellos, o cambian por requisitos de negocio.
* Mejores estandares de calidad de código.
* Integraciones nativas con los stacks de la compañía y que en un futuro pueden absorver con facilidad nuevas funcionalidades.
* El disponer de un BFF en tempo, proporciona al fontal un capa que le facilita las integraciones con las funcionalidades que se desarrollan.
* Escalabilidad de los sistemas y bases de datos.