Generador de Reportes

1. 🧮 Base de Datos

Se utilizó Azure SQL Database para almacenar la informacion de los request y report creados.

2. 🗂️ Almacenamiento de reporte generados y mensajes

Se utilizó Azure Blob Storage para guardar los reportes creados en formato CSV y Azure Queue Storage para almacenar los mensajes recibidos al momento de generar nuevos reportes.

3. ⚙️ Proceso Asíncrono

Se utilizó Azure Functions (Python Queue Trigger) para procesar los mensajes que estaban en el Queue Storage.

4. 🖥️ Frontend

Se creo utilizando Next.js desplegada en Azure App Service.

5. 📡 Backend

Se utilizó API Python con FastAPI desplegada en Azure App Service.

6. 🐳 Despliegue en la nube

Para que la aplicación funcionara en un entorno de nube real de forma independiente se creó un Dockerfile con todas las dependencias y configuraciones necesarias y la imagen de Docker se publico en el Azure Container Registry.

🗑️ Implementar Eliminación Completa de Reportes

El sistema Generador de Reportes proporcionado solamente permitia generar nuevos reportes a partir del tipo de pokemon seleccionado, por lo cual como primera tarea era permitir al usuario poder eliminar los reportes. Para ello se implementaron los siguientes cambios en Frontend y Backend:

1. Se agregó un botón de 'Eliminar' a cada fila de la tabla de reportes que se mostraba en la UI.

2. Implementación de una ventana modal que se muestra al usuario cuando hace click en el botón, pidiendo la confirmacion de dicha acción antes de proceder.

3. Creación e implementacion de un nuevo endpoint que permitia eliminar el registro de la base de datos y el archivo (reporte) CSV correspondiente.

4. Manejo de posibles errores que se podrian presentar tanto al eliminar el registro como el archivo.

5. Mejoras en la UI/UX, como actualización de la tabla y mensaje de confirmación cuando se elimino correctamente.

📊 Enriquecer Reporte con Detalles del Pokémon

Los reportes generados por el sistema solo contenian dos campos: el nombre (name) y la url del pokemon (url). Por lo cual se solicitaba modificar este proceso para incluir mas información del pokemon utilizando la url existente.
Para esto se implementaron los siguientes cambios en el worker (Azure Function) que era el responsable de obtener y crear los archivos CSV:

1. Luego de obtener la lista inicial de Pokemon con el name y url de cada uno, se procedio a iterar sobre cada pokemon utilizando la url para obtener otros datos como height, weight, sprite, generation, types, stats (hp, attack, defense, special-attack, special-defense, speed) y abilities.

2. Para mantener el codigo mas limpio y ordenado se crearon dos nuevas funciones auxiliares get_pokemon_info y get_pokemon_generation. La primera devolvia en una lista todos los campos nuevos y que luego eran agregados a los ya existente. La segunda funcion se implemento para poder obtener la generation del pokemon, ya que este valor no se encontraba directamente a traves de la url inicial y se necesitaba hacer una tercera petición.

3. Manejo de posibles errores que se podrian presentar al momento de hacer el llamado a las request.

🎲 Reportes con Muestreo Aleatorio

El sistema proporcionado estaba creado para generar los reportes utilizando todos los pokemon que pertenecian a una categoria (type), por lo cual se solicitaba agregar una opcion en donde el usuario pudiera ingresar una cantidad (sample_size) que seria el numero total de registro que contendria el informe. Ademas los registros retornados debian ser aleatorios.
Para esta tarea se hicieron cambios en el Frontend, Backend, en el worker (Azure Function) y en la Base de Datos:

1. En la UI se agrego un campo de entrada de tipo numérico, que era en donde el usuario iba a ingresar el valor de registros a retornar.

2. En la base de datos se agrego el campo 'sample_size' del tipo INT NULL a la tabla 'request'. Este campo es para almacenar el numero de registro que se habian solicitado en caso de haber sido enviado.

3. En la parte del backend se agrego el campo 'sample_size' al modelo Pydantic y se modifico el endpoint 'insert_pokemon_request' para que recibiera el nuevo valor y lo enviar al worker.

4. Una vez recibido el 'sample_size' en el worker este solo debia generar los registro dependiendo del 'sample_size' y de forma aleatoria usando como base la colección completa de registros.

5. Manejo de posibles errores que se podrian presentar tanto al momento de hacer el llamado a las request

6. Validación de la entrada ingresada por el susario, que sea un entero positivo.

7. Mejoras en la UI/UX, como mostrar mensajes en caso de que el valor ingresado este incorrecto.