manueldizen/tpe-bddii

Trabajo Práctico Especial para la materia "72.41 - Base de Datos II"

TPE-BDDII

Trabajo Práctico Especial para la materia "72.41 - Base de Datos II"

Introducción y consideraciones

Este repositorio fue utilizado para el desarrollo del Trabajo Práctico Especial de la materia "72.41 - Base de Datos II". El TPE consistía en el desarrollo de una aplicación de pagos digital manejada por el Banco Central de Brasil.

La misma tiene un paralelismo claro con la plataforma de MercadoPago, de amplia adopción en Argentina. Pagos vía QR e instantaneos, diferentes modos de pago.

La consigna mencionaba que la implementación no debía ser exactamente como lo es la aplicación, dado que por supuesto presentaría una complejidad gigante. Por lo que se desarrolló el "esqueleto" de la misma. Esto quiere decir: La aplicación desarrollada permite registrarse en la aplicación únicamente con la obligación de colocar un nombre y un CUIT (de modo de constatar que la persona registrandose es efectivamente quién dice ser, y a su vez para evitar registros dobles), registrar cuentas de banco proporcionando un CBU (asociandola a la cuenta la aplicación correspondiente), y realizar transacciones desde la API de la aplicación indicando CBU fuente y CBU destino (el detalle de la implementación y las limitaciones están detallados debajo).

También se ofrece la posibilidad (aunque para hacer uso de la aplicación va a ser necesario) de utilizar APIs de bancos. Las mismas exponen la creación de usuarios, las busquedas de los mismos mediante CBU, y el depósito/extracción de dinero mediante endpoints. Una vez que se tienen estas cuentas, con un saldo determinado, se deben asociar a la cuenta de la aplicación desde la API de la aplicación, y allí se puede realizar una transacción.

Arquitectura

La arquitectura del sistema (para el desarrollo final y futuro de la aplicación) es como se puede visualizar en la siguiente imagen:

Se modela el sistema de la aplicación con usuarios finales que interactuan con la API de la aplicación por medio de una aplicación movil (no desarrollada hasta el momento). Las conexiones se manejarán mediante un Load Balancer (un simple nginx) con conexiones HTTPS a la API.

Si bien nosotros exponemos las APIs de los bancos "al público", esto es en pos de hacer el sistema usable dentro del scope académico del trabajo. Si esto fuera considerado para trabajar de manera funcional, las APIs de los bancos deberían ser de uso interno unicamente.

Para trabajar con almacenamiento políglota, nosotros decidimos utilizar 3 bases diferentes: PostgreSQL, MongoDB, y CouchDB. Lo primero a notar es la diferencia entre la base relacional y las orientadas a documentos. PostgreSQL se maneja de forma relacional, y a nuestro parecer, lo que se almacena dentro de la aplicación tiene un formato que permite suponer un volumen de datos manejable. Mientras que para los bancos, consideramos que usar bases NoSQL orientadas a documentos tenía mayor sentido, considerando que debemos pensar en la posibilidad de la escalabilidad del sistema. A diferencia de la aplicación, los bancos tendrán que almacenar las n transacciones que se realicen entre cuentas. Además, una misma transacción impacta en la base de datos del banco emisor y del banco receptor, por lo que es necesario considerar todo esto.

El uso de dos bases de datos NoSQL orientadas a documentos se basó en que no todas las entidades bancarias modelan sus datos de la misma manera.

El desafio mas grande del uso de 3 bases diferentes es la interacción con las mismas, logicamente. MongoDB tiene su propio lenguaje definido, que funciona para realizar operaciones sobre sus documentos. Luego, si bien CouchDB ofrece una libreria oficial, se optó por el uso conjunto entre ella y Requests HTTP a la base de forma directa. Estas dos formas fueron extremadamente diferentes de implementar, aunque ambas se tratan de bases orientadas a documentos.

Configuración

El trabajo fue desarrollado con los siguientes stacks:

• Para el desarrollo de la API:
  • Python3
  • FastAPI
  • Uvicorn
• Como bases de datos:
  • PostgreSQL (Utilizada para el almacenamiento de las entidades de la aplicación)
  • MongoDB (Utilizada para el almacenamiento de las cuentas de banco de Galicia y Santander)
  • CouchDB (Utilizada para el almacenamiento de las cuentas de banco de BBVA Francés)

A su vez, se utilizaron diversas dependencias de el entorno de python para administrar las bases de datos mediante APIs estándar desde el código (pymongo, couchdb2, etc.).

Es importante mencionar que tanto PostgreSQL como CouchDB no ofrecen herramientas gratuitas de hosteo (no así Mongo con Atlas), por lo que se trabajó con bases locales provistas mediante las imagenes oficiales de Docker. Es por ello que es necesario asegurarse del correcto funcionamiento del script "inicializador", dado que de eso depende que corran nuestros repositorios.

Para esto, se realizó una serie de pasos detallada para correr este proyecto sin mayores inconvenientes:

1. El trabajo fue ideado para correr en Github Codespaces, una herramienta provista por Github que otorga una maquina virtual UNIX expuesta a través del IDE Visual Studio Code. Por lo que se creo un script, initialize.sh, quién se encarga de instalar los requerimientos previos para correr el trabajo. Para correr esto, lo único que hay que hacer es:

./initialize.sh 

• Nota: Es posible que el archivo no tenga permisos. Para esto, correr el comando: chmod +x initialize.sh

2. De no haber tenido ningún inconveniente, en la ventana ports de la barra inferior (visualizable cuando se abre el espacio de terminal), deberían figurar 2 puertos expuestos: 5984 (de CouchDB) y 5432 (de PostgreSQL). Si alguno NO está siendo expuesto, revisar que error surgió de la inicialización y contactar a los desarrolladores.

3. Un paso extremadamente importante: El repositorio NO CUENTA con el archivo .env con el cual se desarrollo el proyecto. Esto es lógico dado que posee todas las credenciales a las bases de datos utilizadas, mas algunas variables que no deben ser publicadas. Es por eso que se incluyo el archivo .env.fill_in, que tiene los valores de los campos pero vacios. Deben ser llenados para correr, de lo contrario el sistema no correrá.

Nota: Considerando el enfoque académico de la aplicación, se provee el archivo .env de manera pública para facilitar el uso del sistema. Esto se realiza unicamente para la corrección del trabajo práctico, y se desalienta como práctica común.

4. Teniendo todo correctamente seteado, simplemente corremos el script run.sh de la misma forma de antes (aplica la misma aclaración que para el primer script):

./run.sh

5. Esto debería inicializar el servidor donde se hostea nuestra API. Para acceder al mismo, hacer CTRL + CLICK sobre el enlace en negrita de la línea que dice INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit). Este enlace abrirá la siguiente página:

6. Para acceder a la documentación de la API (y para poder utilizarla), lo que se debe hacer es clickear el botón que dice "Ver API". Esto abrirá la documentación de la API en Swagger:

7. Desde esta interfaz, se pueden probar todos los endpoints que ofrece la API de manera gráfica. Cabe destacar que la API fue desarrollada y testeada con esta interfaz, por lo que se recomienda que su uso sea mediante la misma (aunque se puede utilizar mediante HTTP sin ningún inconveniente, es simplemente una interfaz gráfica)

Adicional: Uno podría visualizar la interfaz de "Fauxton", ofrecido por couchdb para ver las bases de datos y documentos existentes. Para acceder desde workspace, hay que dirigirse a la tab de ports, y hacer CTRL + CLICK en la columna de Local Address, de la entrada con el puerto 5984, que es el que expone couch:

Esto abrira la siguiente interfaz:

Para visualizar las DBs, es necesario colocar las credenciales de acceso. Para este trabajo, y dado que ya se encuentran expuestas las credenciales de los repositorios utilizados, se coloca Username: admin, Password: tpebdd2. Debería lanzar la siguiente interfaz:

Desde allí, se puede interactuar con la base, y hasta modificar los documentos de manera directa.

Nota: Esta posibilidad no se ofrece con MongoDB dado que se encuentra en el servidor de Atlas, y para ello sería necesario exponer credenciales personales. Para PostgreSQL, se puede usar el CMDLINE, si así se lo desea. Pero al estar desarrollado en codespaces, es mas dificil conectar un IDE como DataGrip o DB Visualizer.

Funcionamiento

Dentro de Swagger, se encontrará que la API tiene secciones. Las mismas representan las APIs de las diferentes entidades financieras. Los bancos disponibles para operar son Galicia, Santander, BBVA Francés.

Algunos endpoints requieren que se envíe un src_bank o un bank_code. Esta adaptación realizada fue para identificar internamente el esquema de bancos que tenemos.

Es de absoluta importancia que, a la hora de utilizar un banco fuente o destino, se utilice alguno de los siguientes códigos: GAL, STD, FRA. De no utilizarlos, el sistema no comprenderá de que banco se trata, y fallará a la hora de realizar una petición

Repito la aclaración: Usar unicamente los 3 códigos indicados (GAL, STD, FRA). El resto no funcionará

Luego, uno puede utilizar los endpoints libremente.

Integrantes:

Nombre	Legajo
De Simone, Franco	61100
Dizenhaus, Manuel	61101
De Los Ángeles Makk, Azul	61589