Universidad del Perú.

Decana de América

Facultad de Ingeniería de Sistemas e Informática

Escuela Académica Profesional de Ingeniería de Sistemas

Aplicación basada en Microservicios e Interfaz desacoplada

Docente:
GIL CALVO, RUBEN ALEXANDER

Curso:

Sistemas Distribuidos

Integrantes:
- Bancayan Mendoza, Javier Antony
- Lopez Solorzano, Diego Eduardo
- Luque Ayala, Juan Alexis
- Muñua Carrasco, Gerson D' Jesus
 - Perez Llacsa, Pablo
- Muñoz Ñahuero, Daniel

1. Visión del Proyecto

El proyecto espera ser una solución tecnológica viable y multiplataforma para diferentes
empresas, brindando soporte tanto al área de contabilidad como de gestión. Se proyecta
implementar una solución que posea una alta disponibilidad con el objetivo de generar
confiabilidad en los usuarios, así, permite su comunicación con múltiples plataformas al
planear brindar su respuestas mediante archivos JSON.

2. Problemática por resolver

La problemática por resolver en el presente proyecto son los siguientes:

● Falta de disponibilidad de los sistemas de contabilidad y gestión interna de

empresas.
● Incapacidad de las aplicaciones existentes de ser adaptables a las distintas
plataformas existentes.
En el primer problema, se plantea que un sistema tanto de contabilidad, encargado de
facturas, boletas, órdenes de compra, etc., como los sistemas que soportan la gestión
interna de la empresa, contando con módulos como trabajadores, clientes, proveedores,
almacenes, centros de costos, etc., deben tener la capacidad de tener una alta
disponibilidad para los usuarios, ya que estos deben tener la capacidad de acceder a su
información en cualquier momento que lo requieran, independientemente de diversos
factores que puedan afectar el rendimiento o disponibilidad de la aplicación, como es el
caso de la cantidad de los usuarios que accedan a ella, estado del servidor en el que se
encuentre la aplicación, entre otros aspectos.
En el segundo caso, algunas de las aplicaciones existentes se encuentran en una
arquitectura monolito con la interfaz acoplada, que genera la incapacidad de ser
adaptable a distintas aplicaciones y demás. El usuario al requerir una aplicación móvil
deberá desarrollar independientemente del software existente, debido a su incapacidad
de ser multiplataforma.

3. Estado del Arte

En este punto hablaremos sobre las tecnologías que se usarán para desarrollar la
solución a la problemática planteada además de hacer una comparativa entre
otras tecnologías para contrastar porque se opta por las tecnologías escogidas.

3.1 Arquitectura Monolítica

La arquitectura monolítica consiste en crear una aplicación autosuficiente que
contenga absolutamente toda la funcionalidad necesaria para realizar la tarea
para la cual fue diseñada, sin contar con dependencias externas que
complementan su funcionalidad. En este sentido, sus componentes trabajan
juntos, compartiendo los mismos recursos y memoria. En pocas palabras, una
aplicación monolítica es una unidad cohesiva de código.
Un monolítico podría estar construido como una sola unidad de software o
creada a partir de varios módulos o librerías, pero lo que la distingue es que al
momento de compilarse se empaqueta como una sola pieza, de tal forma que
todos los módulos y librerías se empaquetan junto con la aplicación principal.
El estilo monolítico no es algo que haya sido planeado o ideado por alguien en
particular, sino que todas las aplicaciones al inicio de la computación nacían con
este estilo arquitectónico. Solo hace falta recordar los sistemas antiguos, donde
todo funcionaba en una súper computadora, la cual realizaba todas las tareas.
Recordemos que al inicio no existía el internet, por lo que no había forma de
consumir servicios externos para realizar determinadas tareas, en su lugar, el
sistema monolítico tenía que implementar absolutamente toda la funcionalidad
necesaria para funcionar, y de esta forma ser auto suficiente.
Con el tiempo, llegó el internet y con ello la posibilidad de consumir servicios
externos, llegaron arquitecturas modulares que permitían separar el código en
unidades de software más manejables, cohesivas y fácil de administrar, sin
embargo, con todos estos avances, siguen existiendo las aplicaciones
Monolíticas, las cuales son vistas por los inexpertos como algo malo o incluso
como un Anti patrón, pero la realidad es que esto está muy alejado de la
realidad.
A pesar de todo el estigma que tienen las aplicaciones monolíticas, la realidad es
que, hasta el día de hoy, las aplicaciones monolíticas siguen teniendo un
protagonismo muy importante y siguen existiendo casos donde son totalmente
indispensables para mantener la operación de las empresas.
Puede parecer un poco tonto el solo hecho de pensar en hacer una aplicación
monolítica hoy en día, sin embargo, todavía hay escenarios donde son
totalmente necesaria, solo imagina el sistema venta y facturación de una pequeña
empresa, el software de los equipos médicos, programas de escritorio, como
procesadores de texto o incluso sistemas más completos como los clásicos CRM
o ERP.
Todos estos sistemas muchas veces funcionan de forma independiente, sin
acceso a internet y necesitan una autonomía total, solo imagina que un equipo
médico no funcione si no se puede conectar a internet o que necesite de servicios
externos para operar, eso podría costar vidas, o que el cajero de una tienda no
pueda vender o administrar su inventario porque una dependencia no está
disponible, eso podría costar la pérdida de ventas. Lo cierto es que las
aplicaciones monolíticas son cada vez menos atractivas, pero hasta el día de hoy,
tiene aplicaciones donde difícilmente podrán ser reemplazadas.
 Figura 1 : Arquitectura Monolítica

Fuente: (Introducción a la Arquitectura de Software,2018)

3.2 Arquitectura de Microservicios

La arquitectura de microservicio o microservicios, una variante del estilo
estructural de la arquitectura orientada a servicios (SOA).Se suele considerar la
arquitectura de microservicios como una forma específica de realizar una
arquitectura orientada a servicios.
El nombre de “Microservicios” se puede mal interpretar pensando que se trata de
un servicio reducido o pequeño, sin embargo, ese es un concepto equivocado,
los Microservicios son en realidad pequeñas aplicaciones que brindan un
servicio, y observa que he dicho “brinda un servicio” en lugar de “exponer un
servicio”, la diferencia radica en que los componentes que implementan un estilo
de Microservicios no tiene por qué ser necesariamente un Web Services o
REST, y en su lugar, puede ser un procesos que se ejecuta de forma programada,
procesos que mueva archivos de una carpeta a otra, componentes que responde a
eventos, etc. En este sentido, un Microservicios no tiene porqué exponer
necesariamente un servicio, sino más bien, proporciona un servicio para resolver
una determinada tarea del negocio
Un microservicios es un pequeño programa que se especializa en realizar una
pequeña tarea y se enfoca únicamente en eso, por ello, decimos que los
Microservicios son Altamente Cohesivos, pues toda las operaciones o
funcionalidad que tiene dentro están extremadamente relacionadas para resolver
un único problema.
En este sentido, podemos decir que los Microservicios son todo lo contrario a las
aplicaciones Monolíticas, pues en una arquitectura de Microservicios se busca
desmenuzar una gran aplicación en muchos y pequeños componentes que
realizar de forma independiente una pequeña tarea de la problemática general.
En resumen los microservicios son un enfoque arquitectónico y organizativo
para el desarrollo de software donde el software está compuesto por pequeños
servicios independientes que se comunican a través de API bien definidas. Cada
servicio se encarga de implementar una funcionalidad completa del negocio.
Cada servicio es desplegado de forma independiente y puede estar programado
en distintos lenguajes y usar diferentes tecnologías de almacenamiento de datos.

Figura 2 : Arquitectura de Microservicios

Fuente: (Introducción a la Arquitectura de Software,2018)

3.3 Comparación entre Arquitectura Monolítica y Microservicios

Luego de haber brindado las definiciones y descrito sobre las arquitecturas de
servicios y arquitecturas monolíticas pasaremos a presentar una comparación
entre ellas, como se aprecia en la tabla 1.
Tabla1 Arquitectura monolítica frente a microservicio

Arquitectura Monolítica Arquitectura de Microservicios

Debido a su gran tamaño y Debido a su pequeño tamaño y baja

complejidad, son difíciles de depurar, complejidad, son relativamente fáciles
mantener y evolucionar. de depurar, mantener y evolucionar.

El desarrollo y las pruebas se Desarrollo y pruebas aceleradas que

ralentizan ya que, debido a las permiten la entrega continua ya que,
dependencias entre los módulos, debido a su independencia, cada
hacer cambios en un módulo puede microservicio se puede cambiar e
requerir reiniciar toda la aplicación. implementar por separado.

Dado que varios módulos pueden Los microservicios individuales se

 tener diferentes requisitos de recursos, pueden implementar y optimizar en
la implementación de aplicaciones entornos separados
monolíticas en un solo entorno
generalmente conduce a subóptimos
actuación.

La escalabilidad es limitada porque Cada microservicio se puede escalar

no es posible escalar solo un de forma independiente para mejorar
subconjunto de módulos. la utilización de los recursos.

Dado que se basan en la misma pila Cada microservicio se puede

de tecnología, la flexibilidad de desarrollar utilizando una pila de
desarrollo es limitada. tecnología diferente, lo que conduce a
una mayor flexibilidad.

Dado que la aplicación se trabaja La arquitectura distribuida de los

sobre un solo bloque independiente, Microservicios hace que los puntos de
mitiga gran parte de los errores de falla de una aplicación se
comunicación, red, integraciones, etc. multipliquen, pues cada comunicación
Prácticamente los errores que pueden entre Microservicios tiene una
salir son por algún bug del posibilidad de fallar, lo cual hay que
programador, pero no por factores gestionar adecuadamente.
ajenos.

Las aplicaciones Monolíticas son La naturaleza distribuida de los

significativamente más rápidas debido Microservicios agrega una latencia
a que todo el procesamiento lo realiza significativa que puede ser un
localmente y no requieren consumir impedimento para aplicaciones donde
procesos distribuidos para completar el performance es lo más importante,
una tarea. por otra parte, la comunicación por la
red puede llegar a ser incluso más
tardado que el proceso en sí.
Fuente : Elaboración propia

En la tabla 1 podemos ver algunas grandes diferencias entre ambas arquitecturas,

haciendo una comparación y discernir sobre cuál es la adecuada para
implementar las solución
Con las arquitecturas monolíticas, todos los procesos están estrechamente
asociados y se ejecutan como un solo servicio. Esto significa que, si un proceso
de una aplicación experimenta un pico de demanda, se debe escalar toda la
arquitectura. Agregar o mejorar las características de una aplicación monolítica
se vuelve más complejo a medida que crece la base de código. Esta complejidad
limita la experimentación y dificulta la implementación de nuevas ideas. Las
arquitecturas monolíticas aumentan el riesgo de la disponibilidad de la
aplicación porque muchos procesos dependientes y estrechamente vinculados
aumentan el impacto del error de un proceso.
Con una arquitectura de microservicios, una aplicación se crea con componentes
independientes que ejecutan cada proceso de la aplicación como un servicio.
Estos servicios se comunican a través de una interfaz bien definida mediante
API ligeras. Los servicios se crean para las capacidades empresariales y cada
servicio desempeña una sola función. Debido a que se ejecutan de forma
independiente, cada servicio se puede actualizar, implementar y escalar para
satisfacer la demanda de funciones específicas de una aplicación.
3.4 Interfaz Acoplada
Para entender este concepto primero nos apoyaremos en la arquitectura MVC,
que es muy conocida y usada en la carrera de Informática.
Hemos defendido este patrón de arquitectura de software porque separa:
● El Modelo: los datos y la lógica de negocio. Envía a la vista aquella parte
de la información que en cada momento se le solicita para que sea
mostrada. Las peticiones de acceso o manipulación de información
llegan al modelo a través del controlador.
● El Controlador: encargado de gestionar los eventos y las comunicaciones
entre la vista y el modelo.
● La Vista: interfaz de usuario. Presenta la información procedente del
modelo.
Al separar el desarrollo en tres capas se simplifica el trabajo y se facilita la
reutilización de código y la separación de conceptos, características que buscan
facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.
Los primeros desarrollos de aplicaciones web plantean un enfoque de cliente
ligero en el que casi todas las funciones, tanto de la vista, el modelo y el
controlador recaen en el servidor. En este enfoque, el cliente manda la petición
de cualquier enlace o formulario al controlador y después recibe de la vista una
página completa y actualizada. Tanto el modelo como el controlador (y buena
parte de la vista) están completamente alojados en el servidor.
Aquellas primeras aplicaciones eran percibidas por el usuario como lentas y
poco dinámicas en comparación con las aplicaciones de escritorio. Para
solventar este problema se fueron trasladando cada vez más partes de la vista al
lado del cliente. Es decir, al navegador.
Típicamente se empezaron a actualizar partes de la vista usando AJAX.
Normalmente con la ayuda de librerías como jQuery. En consecuencia, las
tecnologías propias del front-end (HTML, CSS y JavaScript) fueron tomando
cada vez mayor protagonismo.
Sin embargo, la interacción del usuario no estaba resultando todo lo dinámica y
fluida que esperábamos si la comparábamos con las aplicaciones de escritorio y
las ya masivamente implantadas aplicaciones móviles.
Al querer dar respuesta a los nuevos retos planteados descubrimos que en la
mayoría de nuestras aplicaciones el teórico desacoplamiento de la vista no era
[Link] de las pruebas de ello era que las páginas (JSP, PHP, [Link]…) que
componían el interfaz del usuario ejecutaban código en lenguajes de
programación propios del back-end. Como Java, PHP o [Link].
Este código se ejecutaba en el servidor y obligaba al navegador a recargarse para
poder acceder a las nuevas pantallas. Esto puede definir de mejor manera lo que
es una interfaz desacoplada , donde la vista de la aplicación es cargada en el lado
del servidor y luego enviada al cliente.

3.5 Interfaz Desacoplada(Headless)

El paradigma de arquitectura Headless o interfaz desacoplada se basa en un
principio sencillo, en separar la cabeza (el frontend) del cuerpo (el backend). En
otras palabras, hacer que el backend funcione de manera independiente,
entregando los contenidos almacenados en la Base de Datos (BBDD) al frontend
a través de Restful APIS.

La ventaja inmediata de esto es que te permite tener lenguajes completamente

distintos entre los dos extremos de tu web. Puedes actualizar completamente la
interfaz de tu sitio, sin necesidad de hacer ningún tipo de cambio en cómo
almacenar tu contenido. Únicamente es necesario modificar la manera en la que
se lo proporcionas al frontend.

Esto resulta especialmente útil para las empresas que tienen múltiples sitios y
desean abaratar costos de operación. La arquitectura Headless les permite
centralizar su backend en una sola interfaz de administración, la cual
proporciona las APIS que serán consumidas por las diferentes páginas web de la
compañía.
3.6 Comparación entre Interfaz Desacoplada y Acoplada
Luego de haber brindado las definiciones y descrito sobre las interfaz
desacoplada y acoplada pasaremos a presentar una comparación entre ellas,
como se aprecia en la tabla 2.
Tabla 2 Interfaz Acoplada comparada con interfaz Desacoplada

Interfaz Acoplada Interfaz Desacoplada

Las personas del proyecto deben o al En un sistema desacoplado, al tener

menos deberían ser desarrolladores una plataforma para frontend y otra
Full Stack, porque todo lo que se hace para backend,podremos tener perfiles
en la plataforma afecta a Frontend y Backend, Frontend e incluso
Backend a la vez. diseñadores-maquetadores si se
desacoplan los HTML del Frontend.

Esta arquitectura se acopla mejor para Arquitectura es un poco más

proyectos de poca envergadura, compleja, con lo que en proyectos
 además se necesita un menor número sencillos quizás no sea la solución,
de personal para el desarrollo de la además de necesitar más personas del
aplicación equipo implicadas

El lado del servidor se encuentra Dado que el fronted se carga en el

sobrecargado en tareas ya que el lado del cliente se puede liberar al
fronted,además del backend se cargan servidor del trabajo de generar las
de su lado- pantallas como ocurre cuando se
utilizan tecnologías como JSP, JSF.

Existe cierta latencia cuando se Salvo en la carga inicial de la

realiza una recarga de la página, ya aplicación, el intercambio de
que tenemos todo del lado del información entre cliente y servidor
servidor haciendo esto más pesada la es extremadamente ligero porque en
transmisión de información entre cada petición y respuesta entre cliente
cliente y servidor y servidor lo que se intercambian son
archivos JSON
Fuente : Elaboración propia

4. Tipo de tecnología del Sistema Distribuido

Se ha decidido por implementar una arquitectura basada en microservicios ya que esta
arquitectura se amolda mejor para poder atacar a los problemas planteados
anteriormente, debido a las diferentes ventajas que esta arquitectura provee, entre las
cuales se encuentra:

● Modularidad: Se pueden desarrollar e implementar de forma independiente,

además, un error en alguno de los módulos no afectaría a los demás.
● Escalabilidad: Al ser una aplicación modular, se puede escalar horizontalmente
cada módulo que sea necesario.
● Versatilidad: Se pueden usar diferentes tecnologías y lenguajes de
programación. Lo que permite adoptar cada funcionalidad a la tecnología más
adecuada.
● Rapidez de desarrollo: Al ser los microservicios de un tamaño mucho menor al
de una aplicación convencional, permite un desarrollo menos costoso, así como
el uso de contenedores para realizar el despliegue de la aplicación rápidamente.
● Agilidad: Permite la reutilización de módulos ya desarrollados por terceros.

Por otro aspecto, se planeó que la interfaz se encuentra desacoplada, generando así su
desarrollo en Quasar. Este desacoplamiento genera varias ventajas, entre las cuales se
encuentran:
 ● El backend puede ser utilizado por otras interfaces web y por aplicaciones
móviles. Es decir, los datos y la lógica pueden estar expuestos a través de una
API que brinde servicio a una multitud de interfaces de usuario.
● Los frameworks frontend están muy orientados a la componentización y
encapsulación. De modo que es posible realizar grandes aplicaciones a partir de
infinidad de piezas pequeñas entre sí.
● El intercambio de información entre el cliente y el servidor es extremadamente
ligero debido a que lo que se intercambia en cada petición y respuesta entre
ellos son archivos JSON.

5. Arquitectura de la Infraestructura Distribuida

Software base: Para el desarrollo de la aplicación, se han utilizado diferentes
herramientas: para el desarrollo Lumen 6. Para la base de datos se utiliza el software
PostgreSQL 9.6 y para el contenedor de la aplicación se usa el software Docker
19.03.13 y para la interfaz se usa el software Quasar v1.14.0.

● Lumen 6:
Lumen es un micro-framework para PHP creado que comparte muchos de los
componentes de Laravel, pero Lumen es una versión más liviana de Laravel y orientado
más a la creación de APIs y microservicios, aunque también puedes usarlo para crear
sitios web.

A diferencia de Laravel PHP, archivos y componentes no vienen por defecto en Lumen

(como por ejemplo la integración con Bootstrap y los módulos preestablecidos de
autenticación y registro) pero sí puedes usar el ORM Eloquent y otros importantes
componentes de Laravel en Lumen.

- Enrutamiento HTTP: Se definirá todas las rutas para la aplicación en el archivo.

Las rutas de Lumen más básicas simplemente aceptan un URI y un:
routes/[Link] Closure
- Middleware HTTP: proporciona un mecanismo conveniente para filtrar las
solicitudes HTTP que ingresan a su aplicación. El middleware verifica si el
usuario de su aplicación está autenticado. Si el usuario no está autenticado, el
middleware redirigirá al usuario a la pantalla de inicio de sesión. Sin embargo, si
el usuario está autenticado, el middleware permitirá que la solicitud continúe en
la aplicación. Se debe copiar el ExampleMiddleware que se incluye con la
aplicación Lumen.
- Controladores HTTP: Los controladores pueden agrupar la lógica de manejo de
solicitudes HTTP relacionada en una clase. Los controladores se almacenan en
el directorio. routes/[Link] app/Http/Controllers
- Solicitudes HTTP: Para obtener una instancia de la solicitud HTTP actual a
través de la inyección de dependencias, debe escribir la clase en el constructor o
método de su controlador. El contenedor de servicios inyectará automáticamente
la instancia de solicitud actual; Illuminate\Http\Request
- Respuestas HTTP:todas las rutas y controladores deberían devolver algún tipo
de respuesta para ser enviada de vuelta al navegador del usuario. Lumen
proporciona varias formas diferentes de devolver respuestas. La respuesta más
básica es simplemente devolver una cadena de una ruta o controlador
 ● PostgreSql 9.6:
La base de datos fue diseñada con PostgreSQL 9.1, con la unificación de las siguientes
herramientas administrativas:

- pgAdmin III
- PGAccess
- phpPgAdmin
PostgreSQL es un servidor de base de datos objeto relacional libre, ya que incluye
características de la orientación a objetos, como puede ser la herencia, tipos de datos,
funciones, restricciones,disparadores, reglas e integridad transaccional, liberado bajo la
licencia BSD. Como muchos otros proyectos open source, el desarrollo de PostgreSQL
no es manejado por una sola compañía sino quees dirigido por una comunidad de
desarrolladores y organizaciones comerciales las cuales trabajan en su desarrollo, dicha
comunidad es denominada el PGDG (PostgreSQL Global Development Group).

Características principales:

- Presenta un sistema de alta concurrencia: Presenta un sistema denominado

MVCC, el cual permite que mientras un proceso escribe una tabla, otros puedan
acceder a la misma tabla sin necesidad de verse bloqueados, y cada usuario
obtiene una visión consistente.
- Sistema "Hot Standby": Este proceso permite a los usuarios poder conectarse
con el servidor y ejecutar búsquedas en la bd mientras la misma está en modo de
recuperación o "stand by".
- Soporte nativo: PostgreSQL presenta soporte nativo para los siguientes tipos de
datos; Texto de largo ilimitado, Números de precisión arbitraria, Figuras
geométricas con funciones asociadas, Direcciones MAC, Protocolos de
direcciones IP (tanto IPv4 como IPv6), Bloques de direcciones CDIR, Arrays,
Tipos de datos propios de los usuarios.
- Uso de formato JSON: El formato JSON se convierte en el punto débil de
muchos sistemas de bases de datos relacionales. Sin embargo, PostgreSQL
presenta buenas herramientas con las que es posible indexar elementos y realizar
búsquedas en dicho formato.
- Notificaciones a tiempo real: A pesar de que PostgreSQL no fue diseñada para
ser una BD que trabaje al 100% en tiempo real, si es posible mantener
sincronizado en varios dispositivos un sistema de notificación para cuando se
hacen cambios específicos en la base de datos, gracias a las funciones LISTEN,
UNLISTEN y NOTIFY.
- Registro y guardado de transacciones: es su capacidad de registrar cada
transacción en un WAL (Write-Ahead-Log). Esto permite restaurar la base de
datos a cualquier punto previamente guardado, una especie de "Checkpoint".
- Disparadores o triggers: En PostgreSQL, un disparador se define como la
ejecución de un procedimiento almacenado, basado en una acción determinada
sobre una tabla específica en la base de datos.

Ventajas de PostgreSQL:
 - Instalación y uso gratuito: PostreSQL es un gestor de base de datos de código
libre y completamente gratuito, por lo que podemos instalarlo y utilizarlo las
veces que queramos y en todos los dispositivos que queramos.
- Sistema disponible Multiplataforma: Es compatible con prácticamente todas
las tecnologías y sistemas operativos de la actualidad.
- Estabilidad: presenta un sistema de alta disponibilidad mientras los servidores
están en modo de suspensión o recuperación, por lo que los usuarios pueden
acceder en modo de solamente lectura sin bloquear de forma completa el
sistema.
- Escalabilidad y configuración: Es posible configurar de forma individual
PostgreSQL según los recursos de hardware disponibles en nuestro sistema, por
lo que podemos ajustar el número de CPU y cantidad de memoria disponible
para un funcionamiento óptimo.
- Estándar SQL: Implementa la mayor parte de las funcionalidades principales
del estándar SQL, por lo que se puede realizar de forma sencilla el incluir
consultas y scripts de otros motores de bases de datos,
- Herramienta gráfica: Incorpora una herramienta gráfica para la administración
de las bases de datos de forma fácil e intuitiva, por la cual podemos ejecutar
sentencias SQL, realizar copias de seguridad o tareas de mantenimiento.
- Robustez y fiabilidad: PostgreSQL cumple con la característica y protocolo
ACID, lo que significa Atomicidad, Consistencia, Aislamiento y Durabilidad
(siglas en inglés). Por ello, se garantiza la información de la base de datos y
fiabilidad en el sistema.
- Soporte y ayuda: A pesar de no contar con soporte telefónico o en línea, existe
una infinidad de foros y páginas para nuestra ayuda. Además, la comunidad de
PostreSQL es una de las más activas.

● Docker 19.03.13:
Es una tecnología de contenedorización de código abierto para crear y contener sus
aplicaciones. Docker actúa como una aplicación cliente-servidor con:
- Un servidor con un proceso de demonio de larga ejecución dockerd.
- API que especifican interfaces que los programas pueden usar para comunicarse
e instruir al daemon Docker.
- Un cliente de interfaz de línea de comandos (CLI) docker.
La contenerización es cada vez más popular porque los contenedores son:

- Flexible : incluso las aplicaciones más complejas se pueden contener en

contenedores.
- Ligero : los contenedores aprovechan y comparten el kernel del host, lo que los
hace mucho más eficientes en términos de recursos del sistema que las máquinas
virtuales.
- Portátil : puede compilar localmente, implementar en la nube y ejecutar en
cualquier lugar.
- Acoplamiento flexible : los contenedores son altamente autosuficientes y están
encapsulados, lo que le permite reemplazar o actualizar uno sin interrumpir otros.
- Escalable : puede aumentar y distribuir automáticamente las réplicas de
contenedores en un centro de datos.
 - Seguro : los contenedores aplican restricciones y aislamientos agresivos a los
procesos sin que el usuario requiera ninguna configuración.
API, CLI y formatos de archivo de la plataforma Docker:

- Formatos de archivo:
- Dockerfile: Define el contenido y el comportamiento de inicio de un solo
contenedor
- Compose File: Define una aplicación de varios contenedores
- Interfaces de línea de comandos (CLI)
- Docker CLI:La CLI principal para Docker, incluye todos los docker
comandos
- Compose CLI: La CLI para Docker Compose, que le permite crear y
ejecutar aplicaciones de varios contenedores
- Daemon CLI(dockerd): Proceso persistente que gestiona contenedores.
- Interfaces de programación de aplicaciones (API)
- Engine API:La API principal de Docker, proporciona acceso
programático a un demonio
- Registry API: Facilita la distribución de imágenes al motor.
- Template API: Permite a los usuarios crear nuevas aplicaciones de
Docker mediante el uso de una biblioteca de plantillas.

● Quasar v1.14.0:
Quasar es un marco de trabajo basado en [Link] de código abierto con licencia del MIT,
que permite, crear rápidamente responsive++ websites/apps en muchos flavours:
● SPAs (Single Page App)
● SSR (Server-side Rendered App) (+ optional PWA client takeover)
● PWAs (Progressive Web App)
● BEX (Browser Extension)
● Mobile Apps (Android, iOS, …) through Cordova or Capacitor
● Multi-platform Desktop Apps (using Electron)
Quasar está repleto de excelentes funciones listas para usar.
● Minificación de HTML / CSS / JS
● Destrucción de caché
● Temblor de árbol
● Mapeo de fuentes
● División de código con carga diferida
● Transpiling ES6
● Código de rayado
● Funciones de accesibilidad
 6. Arquitectura de la Aplicación Distribuida
Diseño:

Modelo de Datos:
Componentes:
Servidor de base de datos:

Encargado de el almacenamiento de la base de datos cliente

Servidor de Front End:

Encargado de almacenar el sistema web o móvil, enviar las solicitudes y recibir las
respuestas en Json

Servidor de back End:

Encargado de almacenar los servicios API, recibir las solicitudes y enviar las respuestas
en Json

Microservicios:
Maestro:

Encargado de la gestión de clientes, proveedores ,trabajadores, centros de costos, etc.

Entradas:

Encargado exclusivamente de la gestión de documentos, como órdenes de compra,

factura de compra, guías de entrada.

Salidas:

Encargado exclusivamente para las cotizaciones ,guías de salidas, facturas de ventas u

otros documentos de salida.