VolverBack

Proyecto ServerlessServerless Project

Repositorio Serverless del Proyecto Repositorio API del Proyecto Repositorio Infraestructura del Proyecto Repositorio Base de Datos del Proyecto Repositorio UI del Proyecto

Resumen

PokeQueue es una aplicación base desplegada en Azure que genera reportes en CSV de forma asíncrona: una UI en Next.js, una API en FastAPI, una base de datos SQL Server, Blob Storage para los archivos y una Azure Function (Python) que procesa los reportes en segundo plano. El proyecto consistió en extenderla con nuevas funcionalidades sin romper su despliegue.

Logros clave

  • Eliminación completa de reportes (UI con modal de confirmación, endpoint DELETE, procedimiento almacenado con borrado lógico y borrado del CSV en Blob Storage).
  • Reportes enriquecidos: el worker serverless consulta PokeAPI por cada Pokémon y agrega hp, ataque, defensa, ataque especial, defensa especial, velocidad y habilidades al CSV.
  • Reportes con muestreo: el usuario define cuántos registros desea, y el valor viaja por la UI, la API, la base de datos y el worker.
  • Cambios coordinados en cinco repositorios (UI, API, serverless, base de datos e infraestructura).

Stack

Next.js / React, FastAPI (Python), Azure Functions, Azure Blob Storage, SQL Server, Docker, Terraform.

Objetivo del Proyecto

Extender y adaptar esta aplicación base, añadiendo nuevas funcionalidades y demostrando habilidad para modificar y mejorar un sistema existente que debe permanecer desplegado y funcional en Azure.

Arquitectura del Sistema

DiagramaPokeQueue

Tareas a Realizar (Total: 90 Puntos)

Tarea 1: Implementar Eliminación Completa de Reportes (25 Puntos)

Frontend (NextJs)

  • Se ha añadido un botón de eliminar en cada fila de reporte, añadiendo una modal de confirmación como paso extra de seguridad, y al confirmar la eliminación se hace una llamada a la API que borra los registros de reporte de la Base de Datos y el BLOB Storage. Al llegar la confirmación al Front se refresca la lista de los reportes.

Botón eliminar

Modal confirmación

Confirmación eliminación

El registro 65 se ha eliminado:

Registro eliminado

Lista refrescada:

Lista actualizada

Backend (FastAPI)

  • Se ha creado un Endpoint de la API que recibe una solicitud HTTP con el método DELETE con el ID del elemento a eliminar.
  • Este Endpoint desencadena una serie de acciones:
    • Primero, revisa si el elemento está “eliminado en la base de datos”, si lo está, lanza un estado 404, si el elemento no está “eliminado”, entonces se elimina de la base.
    • Una vez eliminado el elemento de la base de datos, va a eliminar el archivo CSV del BLOB Storage, y una vez realizado se envía la respuesta del Endpoint.

Demostrando registro en la DB:

Registro en DB

Demostrando registro en el BLOB:

Registro en blob

Enviando petición:

Petición DELETE

Elemento eliminado:

DB después de eliminar

Blob después de eliminar

Estado después de eliminar

La captura anterior no estaba actualizada y solo debían estar el reporte 63 y 64

Estado final

Procedimiento almacenado para eliminar reportes:

ALTER PROCEDURE pokequeue.delete_poke_request(@id int)
AS
SET NOCOUNT ON;
BEGIN

UPDATE pokequeue.[requests]
	SET [active] = 0
where id = @id AND [active] != 0;

IF @@ROWCOUNT > 0
	SELECT 1 AS response;
ELSE
	SELECT 0 AS response;

END;

EXEC pokequeue.delete_poke_request 70;

Tarea 2: Enriquecer Reporte con Detalles del Pokémon (40 Puntos)

Worker (Azure Function - Python)

  • Los archivos CSV que contenían como datos relevantes el nombre y la URL de información del Pokemon, ahora han sido actualizados agregando más campos con datos relevantes como hp, ataque, defensa, ataque-especial, defensa-especial, velocidad y un campo donde se guardan varias habilidades.

  • Estos datos han sido obtenidos realizando otro consumo a la PokeAPI por medio de un URL único por cada Pokemon del tipo que se obtuvo.

  • Las funciones que viven en el Azure Functions como servicio “Serverless” han sido actualizadas para poder generar archivos CSV con más contenido.

Datos extendidos

Tarea 3: Reportes con Muestreo Aleatorio (25 Puntos)

Frontend (Next Js)

  • En la UI antes de generar un nuevo reporte se solicita ingresar un número para la cantidad de registros deseados en el CSV del reporte

Campo cantidad

Backend (API FastAPI)

  • Se ha modificado el Endpoint de Backend para la creación de reportes para que se pueda obtener el número de Pokemons.
  • Se ha modificado la base de datos añadiendo un campo de la cantidad de muestras que se desean registrar en el reporte

Modificación BD

Worker (Azure Function - Python)

  • La Function App que hace el proceso Background ha sido modificada para poder obtener el número de registros por reporte, y a partir de ese número filtrar la cantidad de Pokemon que se va a registrar en el reporte.

En este ejemplo se pidieron 20 registros para el reporte:

Reporte 20 registros

En la UI se ha agregado el campo de la cantidad de registros en el reporte:

Cantidad en UI

Overview

PokeQueue is a base application deployed on Azure that generates CSV reports asynchronously: a Next.js UI, a FastAPI API, a SQL Server database, Blob Storage for the files and an Azure Function (Python) that processes reports in the background. The project consisted of extending it with new features without breaking its deployment.

Key achievements

  • Full report deletion (UI with a confirmation modal, DELETE endpoint, stored procedure with soft delete and removal of the CSV from Blob Storage).
  • Enriched reports: the serverless worker queries PokeAPI for each Pokémon and adds hp, attack, defense, special attack, special defense, speed and abilities to the CSV.
  • Sampled reports: the user chooses how many records they want, and the value travels through the UI, the API, the database and the worker.
  • Coordinated changes across five repositories (UI, API, serverless, database and infrastructure).

Stack

Next.js / React, FastAPI (Python), Azure Functions, Azure Blob Storage, SQL Server, Docker, Terraform.

Project Goal

Extend and adapt this base application, adding new features and demonstrating the ability to modify and improve an existing system that must remain deployed and working on Azure.

System Architecture

PokeQueue Diagram

Tasks to Complete (Total: 90 Points)

Task 1: Implement Full Report Deletion (25 Points)

Frontend (NextJs)

  • A delete button was added to each report row, with a confirmation modal as an extra safety step. On confirmation, a call is made to the API that deletes the report records from the Database and the BLOB Storage. When the confirmation reaches the frontend, the report list is refreshed.

Delete button

Confirmation modal

Deletion confirmation

Record 65 was deleted:

Deleted record

Refreshed list:

Updated list

Backend (FastAPI)

  • An API endpoint was created that receives an HTTP DELETE request with the ID of the item to delete.
  • This endpoint triggers a series of actions:
    • First, it checks whether the item is already “deleted in the database”. If it is, it returns a 404 status; if it is not “deleted”, it is removed from the database.
    • Once the item is deleted from the database, it deletes the CSV file from the BLOB Storage, and once that is done the endpoint response is sent.

Showing the record in the DB:

Record in DB

Showing the record in the BLOB:

Record in blob

Sending the request:

DELETE request

Item deleted:

DB after deletion

Blob after deletion

State after deletion

The previous screenshot was not up to date and only reports 63 and 64 should remain

Final state

Stored procedure to delete reports:

ALTER PROCEDURE pokequeue.delete_poke_request(@id int)
AS
SET NOCOUNT ON;
BEGIN

UPDATE pokequeue.[requests]
	SET [active] = 0
where id = @id AND [active] != 0;

IF @@ROWCOUNT > 0
	SELECT 1 AS response;
ELSE
	SELECT 0 AS response;

END;

EXEC pokequeue.delete_poke_request 70;

Task 2: Enrich the Report with Pokémon Details (40 Points)

Worker (Azure Function - Python)

  • The CSV files, whose relevant data was the Pokémon name and information URL, were updated with more fields with relevant data such as hp, attack, defense, special-attack, special-defense, speed and a field storing several abilities.

  • This data was obtained by making another call to the PokeAPI through a unique URL for each Pokémon of the type that was retrieved.

  • The functions that live in Azure Functions as a “Serverless” service were updated to generate CSV files with more content.

Extended data

Task 3: Reports with Random Sampling (25 Points)

Frontend (Next Js)

  • In the UI, before generating a new report, the user is asked to enter a number for the amount of records wanted in the report CSV

Quantity field

Backend (FastAPI API)

  • The backend endpoint for report creation was modified so it can receive the number of Pokémon.
  • The database was modified by adding a field for the number of samples to be recorded in the report

DB modification

Worker (Azure Function - Python)

  • The Function App that runs the background process was modified to get the number of records per report, and from that number filter the amount of Pokémon to be recorded in the report.

In this example 20 records were requested for the report:

20-record report

The records-quantity field was added to the UI:

Quantity in UI

Tecnologías utilizadas:Technologies used: