Tipo de estudio El nivel de profundidad que aborda este proyecto, es el tipo de confirmatorio. Ya que la intención de este análisis es determinar...

Tipo de estudio
El nivel de profundidad que aborda este proyecto, es el tipo de confirmatorio. Ya que la intención de este análisis es determinar qué paradigma tiene un mayor rendimiento en la atención de solicitudes en un API Gateway para un tiempo determinado.
El nivel en la investigación holística es la Integrativa y el holotipo de investigación es confirmatoria . Porque se verificará y demostrará con datos la conclusión final del presente trabajo.
Método de investigación
En aras de obtención de la respuesta planteada en la formulación del problema, es necesario establecer un procedimiento riguroso de manera organizada. Por lo anterior, se define como método de investigación el Método Cuantitativo, en donde a partir de diversas mediciones en la transaccionalidad del API Gateway, se encontrarán diferencias entre paradigmas de programación.
Fuentes y técnicas para recolección de la información
Las fuentes a los que se acudió para el marco referencial son:
Documentación: Se revisó literatura tanto internet, tesis online, sistema BDigital (Biblioteca Digital) de la universidad Distrital Francisco José de Caldas, Trabajos de grado expuestos en RIUD (Repositorio Institucional) de la universidad Distrital Francisco José de Caldas.
Organización del trabajo de grado
El trabajo realizado para el presente proyecto inicia con la Contextualización de la investigación, en donde se puede identificar el planteamiento del problema, definición de la justificación, los objetivos para la investigación, hipótesis, marco referencial, metodología y estudio de sistemas previos.
En una segunda parte, se puede encontrar el Desarrollo de la investigación, la cual la compone los siguientes capítulos:
Fase de Análisis: Se realizó identificación de tecnologías y requerimientos de un Api Gateway.
Fase de diseño: Modelamiento de cada Api Gateway mediante UML, y se acompaña el uso del componente en aplicaciones con microservicios mediante el uso de ADM-Archimate.
Fase de construcción: Se muestra la implementación de cada uno de los Api Gateway haciendo uso de los microservicios.
Fase de pruebas: Se realizan consumos de los servicios expuestos por cada Api Gateway mediante herramientas de análisis de peticiones RestFul.
Para el cierre de la investigación, se presenta una muestreo de la recolección de datos para cada Api Gateway, orientado a objetos y reactivo; se presenta el comportamiento de cada Api Gateway mediante gráficas estadísticas y se realiza comparación de resultados en peticiones atendidas en un lapso de tiempo.
Adicionalmente se discute a cerca de los resultados obtenidos, para finalmente concluir nuestra hipótesis planteada.
Estudio de sistemas previos
Hace aproximadamente un año, el equipo de API de Netflix comenzó a rediseñar la API para mejorar el rendimiento y permitir que los equipos de ingeniería de UI en Netflix optimicen las aplicaciones de cliente para dispositivos específicos. Las filosofías del rediseño se introdujeron en una publicación anterior acerca de abarcar las diferencias entre los diferentes clientes y dispositivos [Web5].
Netfilx además de: Disminuir el número de llamados, distribuir el desarrollo de la API, mitigar los riesgos de implementación, Soporta múltiples idiomas, distribuir operaciones, también presentó su arquitectura [Web5].
Arquitectura
Para lograr los objetivos por encima de nuestra arquitectura destilada en algunos puntos clave:
Tiempo de ejecución políglota dinámico.
capa de servicio totalmente asíncrono.
Modelo de programación reactiva.
El siguiente diagrama, Figura 1-8 y las siguientes anotaciones explican la arquitectura:
Figura 1-8: Arquitectura en Api de Netflix
1. Endpoints dinámicos Todos los nuevos puntos finales de servicios web ahora se definen dinámicamente en tiempo de ejecución. Cada equipo cliente puede desarrollar, probar, canarear e implementar nuevos puntos finales sin coordinación (a menos que dependan de la nueva funcionalidad de la capa de servicio API subyacente que se muestra en el elemento 5, en cuyo caso tendrían que esperar hasta que se implementen los cambios antes de presionar su punto final) [Web5].
2. Administración y gestión de códigos Endpoint El código de punto final se publica en un clúster multirregional de Cassandra (replicado globalmente) a través de una API RESTful Endpoint Management utilizada por los equipos de clientes para administrar sus puntos finales [Web5].
3. Lenguaje Runtime JVM políglota dinámico Se puede admitir cualquier lenguaje JVM para que cada equipo pueda utilizar el idioma que mejor se adapte a ellos. El lenguaje Groovy JVM fue elegido como nuestro primer idioma compatible. La existencia de funciones de primera clase (cierres), sintaxis de lista / diccionario, rendimiento y capacidad de depuración fueron todos aspectos de nuestra decisión. Además, Groovy proporciona una sintaxis cómoda para una amplia gama de desarrolladores, lo que ayuda a reducir la curva de aprendizaje del primer idioma en la plataforma [Web5].
4 y 5 API Java Asíncrona + modelo de programación reactiva Adoptar la concurrencia fue un requisito clave para lograr mejoras de rendimiento, pero abstraer los detalles de implementación de ejecución paralela y seguridad de subprocesos de los desarrolladores clientes fue igualmente importante para reducir la complejidad y acelerar su tasa de innovación. El primer paso fue hacer que la API de Java fuera totalmente asíncrona, ya que permite que las implementaciones de los métodos subyacentes controlen si algo se ejecuta simultáneamente o no, sin que cambie el código del cliente. Elegimos un modelo de programación reactivo con un estilo de programación funcional para manejar la composición y los flujos condicionales de devoluciones de llamada asíncronas. Nuestra implementación está modelada a partir de Rx Observables [Web5].
6. Tolerancia a fallos de Hystrix Como hemos descrito en una publicación anterior, todas las llamadas de servicio a los sistemas de back-end se realizan a través de la capa de tolerancia a fallos Hystrix (que se abrió recientemente, junto con su panel de control) que aísla los puntos finales dinámicos y la capa de servicio API de los inevitables fallos que Ocurre mientras se ejecutan miles de millones de llamadas de red cada día desde la API a