1. Introducción y metas
Una empresa de venta de productos busca originar un sistema de venta online denominado DeDe (Decentralized Delivery). Estará centrada en la venta de productos informáticos de diferentes ámbitos (como ratones, teclados…). Este sistema busca priorizar la privacidad de los clientes a través de los principios SOLID. El sistema obtendrá la información de los clientes de los pods de los usuarios siempre que éstos den los permisos necesarios al sistema de venta. Se distinguirá entre usuarios normales y adminstradores. Éstos pueden, además de acceder a la tienda, crear, modificar y eliminar los productos de la base de datos. Los usuarios eligirán los productos que formarán parte de su carro de compra. Cada usuario tiene su propio carro individual.
1.1. Integrantes
-
Ana Fernández Ostio
-
Darío Martínez Bajo
-
Efrén García Valencia
-
Adrián Santamarina Romero
-
Rubén Rubio el Castillo
1.2. Profesores a cargo de la asignatura
-
Hugo Lebredo Buján
-
Jose Emilio Labra Gayo
-
Pablo González
-
Irene Cid Roco
1.3. Información general de los requisitos
A continuación se muestran los requisitos que se puedes encontrar en nuestra aplicación. Se dividen en obligatorios y opcionales
-
El sistema recreará un sistema de compra online donde los usuarios podrán elegir y solicitar productos a comprar.
-
Una vez que el usuario escoja los productos a llevar, el sistema calculará los costes de envío mirando la dirección deseada del usuario en su pod y estableciendo los costes de acuerdo a la distancia del centro de distribución a dicha dirección.
-
Se mostrarán los costes finales de los productos a comprar y, una vez que el usuario tome la decisión de comprarlos, registrará el evento que indicará que la venta ha sido completada y se pasará al envío.
-
Los usuarios podrán visualizar los pedidos realizados
-
Se construirá la aplicación usando el framework React y Typescript.
-
El producto acabado tiene que ser accesible y estar desplegado utilizando un sistema de integración continua y un servicio de hosting.
-
Rol de gestores que puedan realizar diferentes acciones como gestión de inventario, cambios de precios, quitar ítems del catálogo, etc.
-
Se añade tambien una vista en el que el administrador pueda ver todos los pedidos que se han realizado.
-
Un usuario puedde actuzalziar el nombre de este dentro de la aplicación
1.4. Objetivos de calidad
| Objetivos de calidad | Motivación | Importancia |
|---|---|---|
Eficiencia |
La aplicación utilizará la menor cantidad de recursos posibles para generar las respuestas a las peticiones, mejorando así los tiempos de respuesta |
Media |
Seguridad |
El usuario debe tener la certeza de que su información personal esté segura para ganar su confianza |
Alta |
Robustez |
Se ha de manejar correctamente las excepciones para evitar que el usuario tenga una experiencia desagradable usando la aplicación |
Alta |
Privacidad |
Solamente el usuario debería tener acceso a su información privada, sin que haya terceras partes implicadas |
Alta |
Transparencia |
Todo lo que se haga en el proyecto permanecerá en un repositorio público para que otra gente lo pueda tener como referencia |
Media |
Comodidad |
La aplicación ha de ser fácil de manejar para gente no experimentada |
Alta |
1.5. Stakeholders
| Rol/Nombre | Expectations |
|---|---|
Equipo de desarrollo |
Aprender a trabajar en equipo con gente que no conocen y familiarizarse con las tecnologías solicitadas en el curso |
Empresa de venta de productos (cliente) |
Una aplicación funcional que satisfaga los requisitos solicitados, especialmente aquellos relacionados con la seguridad |
Cliente |
Poder entrar a la aplicación para realizar las compras que desean de forma segura y cómoda. Introducirán sus productos en un carro de la compra. |
Administrador |
Tener el control de una aplicación robusta y eficiente que incluya la posiblidad de crear, modificar, eliminar productos, ver los usuarios y pedidos |
Inrupt/Empathy |
Entidades colaboradoras del concurso SOLID en el que se puede presentar el proyecto desarrollado durante el curso |
2. Restricciones de Arquitectura
| Restricción | Descripción |
|---|---|
Typescript |
Nuevo lenguaje de programación para todos los integrantes del grupo. |
React |
Libreria JavaScript requerido para construir interfaces de usuario para la web. Aplicación nueva que nunca usamos. |
SOLID |
Principios y tecnologia que nos ayudará a organizar apps, al igual que react, tenemos que investigar sobre ello ya que es la primera vez que la usamos. |
| Restricción | Descripción |
|---|---|
Equipo |
Grupo conformado por 5 personas que no habian trabajado juntos antes. |
Tiempo |
Fecha de entrega limite al final de semestre, 2 horas semanales con el profesor y reuniones del equipo semanales de 1 a 2 horas. |
| Restricción | Descripción |
|---|---|
Arc42 |
Recomendado para realizar la documentación. |
PlantUML |
Programa que permite diseñar y realizar diagramas, generándolos a través de un texto escrito |
3. Alcance y contexto del sistema
En Dede se le ha dado mas importancia a la seguridad y privacidad de nuestros clientes, por lo que para cumplir esto dos atributos de calidad, se seguirán los principios de SOLID utilizando PODS. Un POD es un lugar seguro donde el usario podrá alamacenar la informacion que desee y dar autorización a la aplicación para que se utilice la información que sea necesaria. Cada usuario tendrá un POD propio donde colocará principalmente sus datos personales y la dirección de envío. También hay mas seguridad ya que la contraseña del usuario del será cifrada para despues ser almacenada en la Base de Datos
3.1. Contexto de negocio
| Comunicaciones | Entradas | Salidas |
|---|---|---|
Usuario |
Interacciones con la aplicación |
Respuestas a esas interacciones |
POD del Usuario |
La inforamción relativa a cada usuario para respetar su privacidad |
Información que necesite la aplicación siempre cuando el usuario lo permita |
DeDe |
Venta de productos |
Información que recibe de las APIs y de la base de datos |
Base de datos |
Peticiones por parte de la aplicación DeDe |
Respuesta de la información almacenada en esta base de datos |
EasyPost |
Dirección de envío |
Precio de envío desde el almacén |
PostImages |
Imágenes para mostrar |
Imágenes necesarias para mostrar en la Aplicación |
3.2. Contexto técnico
Se utiliza una arquitectura SOLID para respetar la privacidad del usuario, en este caso la direccion de envio de este.
| Tecnología | Descripción |
|---|---|
POD |
Lugar donde se almacena la información de cada cliente |
DeDe |
Aplicación descentralizada |
EasyPost |
API usada para calcular los precios de envio |
PostImages |
API que guarda las imagenes y las descarga para su uso en la aplicación |
TypeScript |
Lenguaje utilizado para el desarrollo de la aplicación |
React |
Libreria utilizada para generar de las interfaces de la aplicación |
4. Soluciones de estretegia
4.1. Restricciones tecnologicas
-
React: libreria de acceso libre que en este caso se utilizara con TypeScript diseñada para que el diseño de las interfaces web sean más fáciles.
-
Pod Solid: almacenamiento de la inforamción personal de cada usuario.
-
TypeScript: lenguaje de programación con el que está desarrollada la aplicación.
4.2. Deciones tecnologicas
-
Node.js: entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor basado en el lenguaje de programación JavaScript, asíncrono, con E/S de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google.
-
MongoDB: sistema de base de datos NoSQL orientado a documentos. Además MongoDB es de código abierto por lo que se permite una mayor libertad de creación de documentos
-
MUI: Libreria de libre acceso para construir los diferentes componentes que utiliza la aplicación. La mayoria de componentes que se utilizan en nuestra aplicación son de esta librería y son personalizados según se necesita el formato de este.
-
Docker: Automatizacion del despligue medainte contenedores, se han creado dos contenedores, uno para la parte de 'front-end' y otro para 'back-end'
-
AWS: Depligue de la página.
-
EasyPost: API que calcula el precio de envío en funcion de una dirección
-
PostImages: API utilizada para poder utilizar las imagenes en nuestra aplicación.
-
SuperTest y Jest: Utilizado para poder realziar las diferentes pruebas.
4.3. Decisiones de organización
-
Revisiones y reuniones acordadas con antelación se realizarán a través de la aplicación Microsoft Teams.
-
Mensajería instantanea para acordar aquellas reuniones que se realicen de forma online, también para avisar de cambios pequeños.
-
GitHub para reflejar el trabajo que se esta realizando de varias formas:
-
Rama individual para cada uno, donde deberá realizar su trabajo. Rama Developer donde se iran incluyendo los cambios de todos los miembros para despues poder realizar de una manera más sencilla los cambios a master.
-
Uso de wikis para recoger todo lo acordado en las reuniones y del registro arquitéctonico.
-
Uso de issues para indicar las cosas que tiene que realizar cada miembro del equipo.
-
Uso de Actions para commprobar el correcto funcionamiento de la aplicación
-
Uso de Tableros para controlar como esta siendo el desarrollo del trabajo, se dividieron en 4 tableros:
-
FrontEnd
-
BackEnd
-
Documentación
-
Despliegue
-
-
5. Building Block View
5.1. 5.1. Whitebox Overall System
El siguiente diagrama permite mostrar las distitnas capas de la aplicación y la manera en la que el usuario interactúa con ella:
Motivación
El usuario tendrá un POD con el que la aplicación recogerá su información de contacto para calcular el coste de los gastos de envío de los productos. A parte de esto, el usuario podrá interactuar con la aplicación para registrarse y poder realizar pedidos con los productos que desee.
Cajas negras |
Descripción |
Usuario |
Interactúa con la aplicación y es propietario de un POD con su información de contacto. |
DeDe |
Sistema que permite a los usuarios realizar los pedidos con los productos que desee. |
POD |
POD del usuario que contiene su informaciñon personal. |
5.2. 5.2. Nivel 1
Motivación
El usuario de la aplicación interactuará con la WebApp de la misma, es decir, el frontend de la aplicación y éste a su vez intercambia las entradas que recibe de parte del usuario con la API Rest que persiste dichos datos en la BBDD.
Nombre |
Responsabilidad |
WebApp |
Frontend de la aplicación con la que el usuario interactúa. |
API |
API Rest de la apliación que conforma el backend de la aplicación, al que se le harán peticiones y se relaciona con la BBDD. |
BBDD |
Base de datos donde se persiste la información que maneja la aplicación. |
5.3. 5.3. Nivel 2
Motivación
Se definen las distintas páginas de la aplicación en la WebApp con las que el usuario interactuará para realizar sus pedidos, cada una de estas páginas intercambiará datos con el API Rest, conformado por los Routes, Controllers y Models descritos en la parte inferior.
Log-In |
El usuario podrá iniciar sesión en la aplicación con sus datos de registro. |
Registro |
El usuario podrá registrarse introduciendo sus datos, para posteriormente iniciar sesión. |
Productos |
Listado de productos que el usuario podrá añadir al carrito, y posteriormente realizar un pedido. |
Home |
Página principal de la aplicación |
Carrito |
Carrito de la compra donde se guardan los productos que el usuario quiere. |
Pago |
Pantalla de pago de la aplicación para realizar el mismo. |
Routes |
Rutas del backend para hacer las peticiones correspondientes, a éstas se le añaden las funcionalidades a través del controlador. |
Controller |
Define las funciones que se van a enrutar e interactúa con los modelos de la BBDD. |
Model |
Modelos definidos en la BBDD, se encargan de persistir los datos. |
6. Runtime View
A continución se muestran diferentes escenarios que se puedene encontrar en la aplicación
6.1. Añadir productos
El administrador rellenará un formulario con los detalles del producto que se mandará a la aplicación. Desde ahí se manda la información necesaria a la base de datos para que se almacene el nuevo producto correctamente.
6.2. Administrar productos
El administrador podra administrar todos los productos de la web. Se le mostrará una tabla con todos los productos, su información, stock y con dos opciones, editar el producto o eliminarlo.
6.3. Eliminar productos
El administrador podra eliminar el producto que desee desde la misma ventana donde se administran los productos.La aplicación borrará el producto seleccionado.
6.4. Administrar pedidos
El administrador podra administrar todos los pedidos de la web. Se le mostrará una tabla con todos los pedidos y su información.
6.5. Filtro de productos
El usuario tras realizar el login en la aplicación y ver los diferentes productos que hay, podrá utilizar los filtros situados en la parte izquierda de la página para realizar una búsqueda más precisa. Tras selccionar los filtros que el usuario vea convenientes. La aplicación pedirá a la base de datos donde se encuentren todos los productos, aquellos que el filtro muestre. Tras ello, la base de datos, retornara los productos que cumplan esos filtros a la aplicación. La aplicación mostrará los productos al usuario.
6.6. Compra de productos
El usuario tras haber añadido uno o varios productos al carrito de la compra irá a dicho carrito y comprará los productos, la aplicación gestionará la forma de pago y consultará el Pod del usuario para extraer la información necesaria.
6.7. login
El usuario debe introducir sus credenciales en la aplicación y estas serán validadas con la vase de datos, si son correctas accederá a la aplicacion con su cuentas y sino se le mostrará un mensaje de error
6.8. Cerrar sesión
Una vez que haya acabado, el usuario podra cerrar sesión para no mantener su cuenta activa
6.9. Mostrar historial de ventas administador
El administrador pedirá el historial de ventas a la base de datos.
6.10. Mostrar historial de pedidos del usuario
El usuario pedirá el historial de sus compras a la base de datos.
6.11. Modificar perfil
El usuario podrá modificar su perfil ya sea cambiando su nombre o apellidos directamente o solicitando un cambio de contraseña. El correo no podrá ser modificado.
7. Perspectiva de Despliegue
7.1. Tecnologías
-
Los datos del usuario serán almacenados en un POD. El entorno de desarollo empleado para el trabajo será Node.js, mientras que emplearemos MongoDB como base de datos principal.
7.2. Infraestructura
-
Interfaz de usuario: Desarrollada como un conjunto de componentes de React
-
Logica de negocio: Funcionamiento de la aplicación
-
Persistencia: basada en una API REST y MongoDB
7.3. Diagrama de Despliegue
8. Conceptos transversales
8.1. Modelo de dominio
8.2. Comentarios del modelo
Dos matizaciones importantes:
-
La primera es que como se puede comprobar en la página web no hay reviews. Eso es que en backend está implementado pero en el front no se incluyó por problemas en el desarrollo. Como sigue siendo una parte de la aplicación de la cual además se hacen tests sobre ello pues se dejan en el diagrama.
-
También con el carro de compra desde el backend tenemos código para guardarlo en la base de datos pero al final no se almacena en MongoDB.
8.3. Internacionalización
La aplicación está construida sobre el lenguaje castellano.
8.4. Seguridad
La seguridad es uno de los aspectos fundamentales de la aplicación. Por ello se aplicarán los principios SOLID y el uso de pods para almacenar la información personal del cliente. Para poder garantizar la seguridad al usuario con sus contraseñas estas serán cifradas.
8.5. Consistencia
Otro aspecto fundamental que perseguimos es garantizar que los datos de los clientes no se corrompan al emplear su aplicación, sin importar el problema que ocurra.
8.6. Usabilidad
Queremos garantizar el tener una interfaz de usuario que resulte cómoda al usuario para que así en un futuro vuelva a emplear la aplicación para sus futuras compras.
8.7. Manejo de excepciones
Se incluirá el código necesario para manejar y capturar los errores procedentes de las diferentes partes de la aplicación. De ser necesario, se le informará al cliente con el mensaje que corresponda.
8.8. Manejo de sesión
Se manejarán las sesiones a través del uso de tokens asignados a cada usuario registrado.
8.9. Estándares de código
El crear código limpio que siga unas estructuras y patrones definidos es base fundamental para crear código que se pueda actualizar en un futuro. Queremos garantizar crear una aplicación al nivel que se puede esperar de un equipo de formado por Ingenieros Informáticos del Software.
8.10. Persistencia
Uso de una base de datos MongoDB para gestionar la parte de almacenamiento y modificación de los productos informáticos en la tienda.
8.11. Prototipado de la aplicación
El formato que se ha escogido para realizar los prototipos de la aplicacion es que esta sea fácil de usar y a la vez siga la forma del resto de aplicaciones del mismo tipo de esta.
8.12. Generación de pruebas
Consideramos fundamental el uso de pruebas unitarias para verificar el correcto funcionamiento de la aplicación.
Para comenzar tenemos la página inicial, esta estara compuesta por aquellos productos que tengan un descuento o sean top ventas de la aplicación.
También se podrá tener acceso a la vista de los productos, la cual ofrece una serie de categorías por si se está buscando algo en especifico.
Una vez se este en la aplicacion se podran realizar varias cosas:
Desde el punto de vista de un cliente:
-
Realizar LogIn en la aplicacion: Para poder acceder a la aplicación es necesario indicar el nombre de email de este como la contraseña que haya indicado anteriormente.
-
Realizar un registro en nuestra aplicación, para ello se deberán indicar unos cuantos campos acerca de la informacion peronal de este.
-
Comprobar los articulos que se desean comprar por parte del cliente
-
Realizar el pago del carrito del usuario
-
Ver mis pedidos realizados
-
Actualización del perfil
Desde el punto de vista de Administrador:
-
Ver todos los pedidos que se han realizado desde la aplicación
-
Ver todos los usuarios registrados en la aplicación, asi como tener un botón para asignar a otro administrador
-
Crear un nuevo producto
-
Ver todos los productos que exiten en la app:
-
Actualizar los valores de productos ya existentes
9. Decisiones de diseño
Restricciones técncias, es decir, se obliga a que el equipo de desarrollo trabaje con las diferentes decisiones:
| Restricciones | Ventajas | Desventajas |
|---|---|---|
React |
Facilidad para realizar las interfaces de usuario |
Framework nuevo para todo el equipo |
TypeScript |
Lenguaje más familiriarizado, no permite fallos en los tipos |
Lenguaje con el que no se ha trabajado |
Almacenamiento de las direcciones en PODs |
Seguridad para el usaurio |
Poco conocimiento del funcionamiento |
Jest |
Compatible con TypeScript |
Nunca se ha trabajado con ello, puede llegar a tardar mucho en devolver el resultado de los tests |
Las siguientes decisiones de diseño tomadas por el equipo de desarrollo, van ordenadas de mayor a menor prioridad:
| Decisiones | Ventajas | Desventajas | Link |
|---|---|---|---|
MongoDB |
Forma sencilla de almacenar la información que necesita la aplicación |
Transacciones no soportadas |
|
Axios |
Forma sencilla de conseguir datos de la Base de Datos |
Al procesar mucha información este puede llegar a subir el tiempo de respuesta para el cliente |
|
MUI |
Se puede personalizar según el cliente quiera conveniente |
Pruebas de aceptación son dificiles de realizar |
|
PostIamges |
Fácil colocación de las imagenes en la aplicación |
Para el administrador de la aplicación puede llegar a costarle asociar una imagen a la página web |
|
SweetAlert2 |
Modales con mejor diseño que los que nos pueden ofrecer MUI |
Se necesita instalar una nueva dependecia al sistema |
|
UUID |
El código que llega a generar es improbable que se vuelva a repetir |
El código para el adminsitrador en el caso de los productos, podria llegar a ser muy largo |
|
Mongoose |
Facilita la conexion con la base de datos |
Nunca ha sido utilizado |
|
Express |
Facilita el diseño la aplicación de forma sencilla y rápida |
Primera vez que se ha trabajado |
|
NodeJS |
Failita el trbajo a la hora de pedir datos a la base de datos |
Es necesario aprender como funciona este sistema |
|
AWS |
Despliegue de la aplicación web en nube |
Se necesita de una cuenta especifica y ademas ,poco conocimeiento sobre este |
|
EasyPost |
Calculo de envio para la aplicación sencillo |
Puede producir errores, centro de distribución se situa en EEUU |
|
JSON Web Token |
Guarda de forma correcta el usuario para controlar sus privilegios |
Puede generar fallos de seguridad |
Decisiones Denegadas
| Decisiones | Ventajas | Desventajas | Link |
|---|---|---|---|
Heroku |
Gratuito y además existen varias formas de desplegar |
Difil despliegue ya que contiene un número máximo de estos y además la documentación de errores no es concisa |
10. Requisitos de calidad
10.1. Árbol de cualidades
10.2. Escenarios de Calidad
| Objetivos de calidad | Motivación | Dificultad |
|---|---|---|
Eficiencia |
Utilización de la menor cantidad de recursos posibles para generar las respuestas a las peticiones, mejorando así los tiempos de respuesta |
Media |
Modificable |
La aplicacicón está dividida en dos partes, BackEnd y FrontEnd, además en ambas partes de podrá añadir nuevas funciones, tantas como el cliente quiera. La reutilización de código será importante, por ejemplo, para visualizar los pedidos, el administrador podrá ver todos los pedidos, pero un cliente solo podrá ver los suyos propios, para ello, se añadirá un filtro al código del administrador. |
Fácil |
Usabilidad |
La aplicación será fácil de navegar, estará preparada para culaquier tipo de edad. Los usuarios en todo momento sabrán en que punto de la aplicación se encuentran. |
Media |
Privacidad |
Solamente el usuario debería tener acceso a su información privada, sin que haya terceras partes implicadas |
Media |
Testabilidad |
La aplicación será testeada utilizando diferentes métodos de pruebas, además de ser porbada con usuarios reales para ver si se cumple todo |
Alta |
11. Riesgos y deudas técnicas
-
Falta de experiencia con las tecnologías, ya sea React, TypeScript o SOLID. Nunca hemos trabajado con estas tecnologías, por lo tanto, empezaremos desde cero y deberíamos realizar búsquedas de información constantes para conseguir manejarlas correctamente. Para solucionarlo hemos buscado información del campo que nos ha sido asignado cada uno y hemos hecho pruebas de funcionalidad para paliar los máximos errores posibles.
-
Posibles problemas al trabajar con GitHub. Pueden surgir problemas a la hora de subir nuestros cambios a GitHub e incluso modificar cambios ya realizados por otros compañeros, para reducir esto lo máximo posible, cada compañero trabajará en su rama y cuando se quiera realizar cambios al proyecto principal se hará un pull request para que otro miembro del equipo lo verifique.
-
Primer proyecto web con un tamaño tan grande. Si bien hemos tenido algo de experiencia con proyectos web, nunca con estas dimensiones ni tecnologías. Para paliar este riesgo, deberíamos buscar bastante información sobre cómo llevarlo a cabo e intentar familiarizarnos con esta forma de trabajo lo antes posible.
-
El tiempo. Tenemos poco tiempo para llevar a cabo los prototipos, entonces habrá que tenerlo en cuenta a la hora de desarrollar y llevar el proyecto lo más al día posible.
-
Posibles vulnerabilidades en el proyecto web. Nunca nos han hablado de este tema en ninguna otra asignatura, por tanto, habrá que tenerlo en cuenta a la hora de desarrollar. Para mitigar este riesgo hemos tenido en cuenta algunos aspectos de seguridad, como el cifrado de contraseñas o un fichero con los datos más sensibles que utilizamos en el proyecto.
-
Código poco claro y sin refactorizar en la parte del backend sobre la gestión de usuarios.
-
Acoplamiento en el frontend a la hora de decodificar el token de sesión, se usa un módulo específico para ello.
-
Almacenamiento de token de sesión en el localStorage, se podría guardar en un nuevo campo de la base de datos, ya que el localStorage es modificable desde el navegador
-
Faltaría refactorizar parte del código del frontend para hacerlo más claro y modificable.
-
Mejoras en la implementación del filtrado de productos en el apartado del listado de los mismos.
-
Mal uso de los tipos de TypeScript en algunas ocasiones por falta de experiencia, por ejemplo, usar el tipo "any" en casos innecesarios
-
Mostrar de una forma poco clara que se está accediendo a un servicio de terceros en el caso de los PODs de SOLID.
-
El carrito del cliente se pierde, no se mantiene por las diferentes ventanas.
-
Falta de mas pruebas sobre el código de front.
12. Glosario
| Término | Definición |
|---|---|
arc42 |
Plantilla para la documentación, comunicación de software y arquitectura del sistema. |
React |
Biblioteca de código abierto diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola página. |
TypeScript |
Lenguaje de programación utilizado para desarollar la aplicación. Es un superconjunto de JavaScript, añade tipos estáticos y objetos. |
Solid |
Proyecto de descentralización web dirigido por Tim Berners-Lee, el objetivo es permitir que los usuarios tengan control de sus datos, incluido el acceso y ubicación de almacenamiento. |
POD |
Lugar donde se almacena la inforamción de cada usuario. Una vez registre la informacion, el propio usuario tendrá el control de acceso a este POD. |
SonarCloud |
Plataforma de análisis de código continuo y online con la que se puede analizar el proyecto y ver los resultados en la nube. |
PlantUML |
Herramienta de código abierto que permite a los usuarios crear diagramas a partir de un lenguaje de texto sin formato. |
Prometheus |
Monitor de código abierto para almacenar las métricas. |
Grafana |
Aplicación que permite visualizar los datos almacenados en Prometheus. |
Axios |
Cliente HTTP basado en promesas. Dependecia isntalada para poder realizar de una manera mas sencilla el juntar front-end y back-end de la aplicación |
PostImage |
Página web para poder almacenar las imagenes de los productos |
MUI |
Libreria de libre acceso para construir los diferentes componentes que utiliza la aplicación |
GitHub |
Plataforma para alojar proyectos utilizando un sistema de veriones Git |
Pencil |
Aplicación de escritorio en la que se puede realizar prototipos de pantallas |
UUID |
Librería que genera cógidos aleatorios donde la probabilidad de que uno sea repetido es mínimo |
SweetAlert2 |
Librería de libre acceso para construir los diferentes componentes modales que se utilizan en la aplicación |
NodeJs |
Entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor basado en el lenguaje de programación JavaScript, asíncrono, con E/S de datos en una arquitectura orientada a eventos |
Express |
Framework de aplicaciones web gratuito y de código abierto para Node. js. Se utiliza para diseñar y construir aplicaciones web de forma rápida y sencilla |
MongoDB |
Sistema de base de datos NoSQL, orientado a documentos y de código abierto |
MongoDB Atlas |
Sistema gestionador de base de datos que se encarga de toda la complejidad de la implementación, la gestión y la recuperación de sus implementaciones en el proveedor de servicios en la nube de su elección |
Mongoose |
Biblioteca de JavaScript que le permite definir esquemas con datos fuertemente tipados |
AWS |
Amazon Web Services es una colección de servicios de computación en la nube pública que en conjunto forman una plataforma de computación en la nube, ofrecidas a través de Internet por Amazon.com |
EasyPost |
API de envío para poder calcular los costes dentro de nuestra aplicación |
JSON Web Token |
Estándar abierto basado en JSON propuesto por IETF para la creación de tokens de acceso que permiten la propagación de identidad y privilegios o claims en inglés |
Jest |
Librería abierta para pruebas en JavaScript desarrollada por Facebook |
Scala |
Lenguaje de programación multi-paradigma diseñado para expresar patrones comunes de programación en forma concisa, elegante y con tipos seguros. Integra sutilmente características de lenguajes funcionales y orientados a objetos |
About arc42
arc42, the Template for documentation of software and system architecture.
By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.
Template Revision: 7.0 EN (based on asciidoc), January 2017
© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.