Académique Documents
Professionnel Documents
Culture Documents
net/publication/329155233
CITATIONS READS
0 61
3 authors, including:
All content following this page was uploaded by Reynaldo Quintero on 09 December 2018.
Facultad de Ingeniería
Asher Kleiman.
Reynaldo Quintero.
Quien suscribe, en condición de autores del trabajo titulado “GraphQL vs REST: una
comparación de rendimiento a nivel práctico.”, declara que: Cedemos a título gratuito, y
en forma pura y simple, ilimitada e irrevocable a la Universidad Metropolitana, los
derechos de autor de contenido patrimonial que nos corresponden sobre el presente
trabajo. Conforme a lo anterior, esta cesión patrimonial sólo comprenderá el derecho
para la Universidad de comunicar públicamente la obra, divulgarla, publicarla o
reproducirla en la oportunidad que ella así lo estime conveniente, así como, la de
salvaguardar nuestros intereses y derechos que nos corresponden como autores de la
obra antes señalada. La Universidad en todo momento deberá indicar que la autoría o
creación del trabajo corresponde a nuestras personas, salvo los créditos que se deban
hacer al tutor o a cualquier tercero que haya colaborado o fuere hecho posible la
realización de la presente obra.
En la ciudad de Caracas, a los treinta y un (31) días del mes de mayo del año 2018
ii
Aprobación
Asher Kleiman
Reynaldo Quintero
INGENIERO DE SISTEMAS
En la ciudad de Caracas, a los veintinueve (15) días del mes de junio del año 2018.
iii
Acta de veredicto
iv
Agradecimientos
v
En primer lugar, a Dios, pues sé que jugó un papel importante en los momentos
más oscuros y más difíciles de la carrera, dándome la fortaleza y las luces que necesitaba
para seguir el camino.
A mi mamá, por sus esfuerzos cada día al pararse a las 6 am a encargarse de
que pudiésemos empezar el día de la mejor manera, por darme el cariño que siempre
necesité, las palabras de aliento, un hombro para llorar en los momentos difíciles y su
confianza plena en las decisiones que tomara, te amo.
A mi papá, por ser mi enciclopedia, mi profesor y guía en todo momento, dándome
siempre la motivación e impulsándome a mejorar y a no conformarme jamás, me has
hecho ser un hombre a tu modelo por lo que estoy muy orgulloso, te amo.
A mi hermano, por ser mi mejor amigo y aconsejarme, hacerme reír con sus
ocurrencias, darme fuerzas en los momentos difíciles e incluso acompañarme en mis
trasnochos, estando también dedicado a compartir mis hobbies para poder pasar tiempo
juntos, te amo.
A Asher, mi compañero de tesis, por acompañarme en esta ruda pero
emocionante aventura, que ahora se convierte en un reto más cumplido por ambos,
uniéndose a todos los otros enfrentados y superados a lo largo de la carrera, que vivimos
desde un principio juntos. En esas batallas te convertiste en mi hermano.
A Victoria, por ser mi apoyo en momentos de crisis, por acompañarme en noches
interminables de redacción y de programación, motivándome con su gran esfuerzo,
dedicación y cariño, por enseñarme que no importa el tamaño de las dificultades, siempre
pueden superarse en compañía y con disposición a hacerlo.
A José Luis, por en primer lugar darnos a Asher y a mí el tema de nuestra tesis y
en segundo lugar por motivarme con su inteligencia y curiosidad. Me enseñaste
muchísimas cosas tanto a nivel profesional, como a nivel estudiantil y personal. Eres una
inspiración y un amigo como pocos.
A Rafael, por en este tiempo darme su apoyo, además de inspirarme a través de
sus historias y su forma de ser, a convertirme en una mejor persona y a disfrutar mucho
más de la vida.
A Alfredo, Marcial y a Eduardo, por ser mis mejores amigos desde que nos
conocimos, a darme las fuerzas en todo momento y ayudarme a disipar todas mis
dudas e inseguridades, además de tenerme en cuenta siempre a pesar de las
distancias. Los quiero como a hermanos.
A Andrés, a Alejandro y Bernardo por ser mis mentores y enseñarme en mi
desarrollo profesional. Sin su apoyo y sus horas de paciencia nada de esto sería posible.
Finalmente, a mi tutor Christian y a la Universidad Metropolitana, gracias por su
apoyo y su guía.
Reynaldo Quintero
vi
Tabla de Contenido
Derecho de autor ii
Aprobación iii
Acta de veredicto iv
Agradecimientos v
Tabla de Contenido vii
Índice de Tablas xi
Índice de Figuras xii
Resumen xiii
Introducción 1
Capítulo I. Tema de Investigación 3
I.1 Planteamiento del Problema 3
I.2 Objetivos 5
I.2.1 Objetivo General 5
I.2.2 Objetivos Específicos 5
I.3 Limitaciones 5
Capítulo II. Marco Teórico 7
II.1 Tecnología y paradigmas del área 7
II.1.1 Application Programming Interface 7
II.1.2 Arquitectura Cliente-Servidor 7
II.1.3 Hyper Text Transfer Protocol 8
II.1.4 Estilo arquitectónico y la tecnología. 10
II.1.5 Underfetching y overfetching 11
II.2 Comunicación con API's 12
II.2.1 Representational State Transfer 12
II.2.1.1 Cliente-Servidor 13
II.2.1.2 Sin Estado 13
II.2.1.3 Caché 14
II.2.1.4 Interfaz uniforme 14
II.2.1.4.1 Identificación de los recursos 14
II.2.1.4.2 Representación 15
vii
II.2.1.4.3 Mensajes auto-descriptivos 15
II.2.1.4.4 Hypermedia como el motor del estado de la aplicación 15
II.2.1.5 Sistema en capas 16
II.2.1.6 Código por demanda 16
II.2.2 GraphQL 16
II.2.2.1 Types 17
II.2.2.2 Esquema 17
II.2.2.3 Queries 19
II.2.2.4 Mutations 20
II.2.2.5 Resolvers 21
II.3 Herramientas del Método Evaluativo 21
II.3.2 ISO 9126 y 25010 22
II.3.2.1 Eficiencia (ISO 9126-3) 22
II.3.2.2 Eficiencia de desempeño (ISO/IEC 25010) 23
II.4 Tecnologías a utilizar 23
II.4.1 Node.js 23
II.4.2 Express 24
II.4.3 Angular 5 24
II.4.4 Herramientas para la Evaluación 24
II.4.4.1 Sizeof 25
Capitulo III. Marco Metodológico 27
III.1 Tipo de estudio 27
III.2 Variables y Operacionalización 27
III.3 Hipótesis planteada 32
III.4 Instrumentos de recolección 32
III.4.1 Tamaño 32
III.4.2 Tiempo 33
III.4.3 Peticiones 34
III.4.4 Caso especial 34
III.5 Diseño de la investigación 35
III.5.1 Recolección de información 35
III.5.2 Acercamiento de la investigación 36
III.5.3 Recolección de datos 37
viii
III.5.3.1 Diseño de marco comparativo 37
III.5.3.2 Plan de pruebas 37
III.5.3.3 Diseño de las API’s 38
III.5.3.4 Diseño del frontend y las herramientas de medición 39
III.5.4 Análisis de datos 39
Capítulo IV. Análisis de Resultados 41
IV.1 Diseño del marco de comparación 41
IV.2 Diseño del caso de estudio 41
IV.3 Desarrollo de las API’s y de su web consumidora 42
IV.3.1 API REST 42
IV.3.1.1 Arquitectura cliente-servidor 42
IV.3.1.2 Sin estado 42
IV.3.1.3 Caché 45
IV.3.1.3 Interfaz uniforme 47
IV.3.1.3.1 Identificación de los recursos 47
IV.3.1.3.2 Representación 47
IV.3.1.3.3 Mensajes auto-descriptivos 48
IV.3.1.3.4 Hypermedia como motor del estado de la aplicación 49
IV.3.1.4 Sistema en capas 49
IV.3.1.5 Código en demanda 49
IV.3.2 API GraphQL 50
IV.3.2.1 Esquema 50
IV.3.2.2 Resolvers 52
IV.3.3 Sitio Web y herramientas de medición 55
IV.4 Mediciones 57
IV.4.1 Tiempo de respuesta 57
IV.4.2 Rendimiento o throughput 61
IV.4.3 Utilización de la memoria 63
IV.4.4 Utilización de caché 66
IV.4.5 Overfetching 67
IV.4.6 Underfetching 69
IV.4.7 Capacidad 71
IV.4.8 Velocidad bajo estrés 71
ix
Capítulo V. Conclusiones y Recomendaciones 75
Referencias Bibliográficas 77
x
Índice de Tablas
Tabla 1: Sección de comportamiento temporal del marco comparativo utilizado en las API’s
desarrolladas. ...........................................................................................................................29
Tabla 2: Sección de utilización de recursos del marco comparativo utilizado en las API's
desarrolladas. ...........................................................................................................................30
Tabla 3: Final de sección de utilización de memoria y sección de capacidad del software del
marco comparativo utilizado en las API’s desarrolladas. ...........................................................31
Tabla 4: Datos de fabricante y especificaciones técnicas de la computadora en donde se
realizaron las pruebas. ..............................................................................................................37
Tabla 5: Resultado de las mediciones para tiempo de respuesta, GraphQL. ............................59
Tabla 6: Resultado de las mediciones para tiempo de respuesta, REST ..................................60
Tabla 7: Resultado de las mediciones para rendimiento, GraphQL. ..........................................62
Tabla 8: Resultado de las mediciones para rendimiento, REST. ...............................................63
Tabla 9: Resultado de las mediciones para utilizacion de memoria, GraphQL. .........................65
Tabla 10: Resultado de las mediciones para utilización de memoria, REST. ............................66
Tabla 11: Resultado de las mediciones para overfetching, GraphQL. .......................................67
Tabla 12: Resultado de las mediciones para overfetching, REST .............................................68
Tabla 13: Resultado de las mediciones para underfetching, GraphQL. .....................................70
Tabla 14: Resultado de las mediciones para underfetching, REST. ..........................................70
Tabla 15: Resultado de las mediciones para velocidad bajo estrés, GraphQL. .........................72
Tabla 16: Resultado de las mediciones para velocidad bajo estrés, REST. ..............................72
xi
Índice de Figuras
xii
Resumen
xiii
Introducción
Las API’s, en el nivel más básico, son aquellas que permiten que un producto o
servicio web se comunique con otros productos o servicios, según Lane (2013). De tal
manera, la información queda abierta para ser utilizada por otros desarrolladores,
negocios o incluso departamentos en una misma empresa. En pocas palabras, estas
API’s permiten la comunicación de información de una forma sencilla entre aplicaciones.
Sin embargo, existen distintos métodos para lograr desarrollar estos mecanismos y, hoy
en día, puede ser complicado para los desarrolladores determinar cuál sería la tecnología
más adecuada para su producto.
1
Ambos mecanismos difieren de forma contundente debido a que en su propio
funcionamiento utilizan paradigmas distintos. Claro está que, cuando se tiene en cuenta
que la diferencia de tiempo con la cual ambos fueron desarrollados es aproximadamente
de unos 15 años, se entiende que ambos mecanismos sean tan distintos; incluso cuando
cumplen con propósitos extremadamente similares. Sin embargo, cada una tiene su
relevancia en el mercado de desarrollo de software y ambas son apoyadas por extensos
grupos de desarrolladores.
2
Capítulo I. Tema de Investigación
Este sería el precedente de lo que hoy en día se conoce como la arquitectura cliente-
servidor en el mundo web, arquitectura que permite la distribución de tareas entre dos
roles: el cliente, que se ocupa de pedir los recursos solicitados; y el servidor, encargado
de suplir dichos recursos. Held (2000) lo define mejor como que el concepto de
cliente/servidor divide funcionalmente la ejecución de una unidad de trabajo entre
actividades iniciadas por el usuario final (cliente) y la respuesta de recursos (servicios) a
la petición de actividad.
En el año 2000, Roy Fielding crea, en su tesis doctoral, un nuevo estilo arquitectural
que permitiría realizar la estandarización de la comunicación entre el cliente y el servidor
a través del Protocolo de transferencia de hipertexto (HTTP por sus siglas en inglés).
Este nuevo estilo arquitectural es denominado ‘Transferencia de Estado
Representacional’ (REST según sus siglas en inglés) y consistió, según Fielding (2000)
en un conjunto de restricciones arquitectónicas que, cuando se aplican como un todo,
enfatiza en la escalabilidad de las interacciones de los componentes, generalidad de las
interfaces, el despliegue independiente de componentes, y componentes intermediarios
para reducir la latencia, hacer cumplir con su seguridad y encapsular sistemas de legado.
En una tesis reciente realizada alrededor de este tema, Eizinger (2017) también
3
declara que REST es un estilo alrededor del modelo de pensamiento usado en la
creación de los estándares que describen la Web: HyperText Transfer Protocol (HTTP),
Uniform Resource Identifier (URI) and HyperText Markup Language (HTML). Esto último,
unido con el hecho de que REST, permitió a la Web a escalar al punto en el que se
encuentra hoy en día, hizo que este estilo fuese el estándar aceptado para realizar la
comunicación HTTP entre el cliente y el servidor. Incluso, debido a su éxito global, REST
se convierte en el estilo preferido para la comunicación con las Application Programming
Interface (API por sus siglas en inglés).
En el transcurso del tiempo desde la creación del estilo REST hasta el día de hoy,
existen múltiples implementaciones del mismo en diferentes tecnologías. Sin embargo,
si bien algunas de ellas no cumplían con todos los diseños fundamentales claves del
estilo REST, ninguna de ellas desafiaba ese estándar. De hecho, según el equipo de
desarrollo ReadMe (2016) el estilo REST fue una estandarización creada por Roy
Fielding en el año 2000 y rápidamente adoptada por empresas como Ebay, Amazon,
Flickr, entre otros.
No es sino hasta el año 2015 que el paradigma del uso del estilo REST se ve
desafiado por una nueva tecnología. Es en este año que la compañía Facebook publica
una tecnología de forma Open Source llamada GraphQL, que es un lenguaje para
obtención de datos de API's que contrasta con REST debido a su flexibilidad: si bien este
último permite estandarizar la comunicación, también le da una rigidez significativa.
4
existentes en la forma de comunicación de una API es la mejor para el desarrollo de un
sitio web?
I.2 Objetivos
I.3 Limitaciones
5
tecnología GraphQL, siguiendo la documentación publicada por Facebook en la web.
Una dificultad que se presentó en esta investigación fue la variedad de software que
existe para llevar a cabo las mediciones sobre las plataformas web desarrolladas. De tal
forma, se tuvo que llevar a cabo un proceso de selección con base en los requerimientos
presentados por las métricas ISO 9126 e ISO 25010.
6
Capítulo II. Marco Teórico
7
El cliente se encarga luego de recibir la información y transformarla para mostrarla
al usuario final, logrando así cumplir con las necesidades que él mismo buscaba
satisfacer mediante la utilización del sistema o programa (Held, 2000).
Esta arquitectura es actualmente utilizada para el acceso a internet: un navegador
es utilizado como cliente, quien hace un conjunto de peticiones a diferentes servidores a
través del Hyper Text Transfer Protocol, explicado más adelante, para poder acceder a
los diferentes sitios web en Internet y a los servicios que estos ofrecen. En la figura 1
puede observarse esta comunicación.
8
de ahora en adelante IETF. La más importante de las publicaciones en lo que respecta
a HTTP es la RFC 2616, que sale junto al protocolo HTTP/1.1 para convertirlo en el
estándar de Internet (Grigorik, 2013).
En este documento, se define HTTP/1.1 como un protocolo a nivel de aplicación para
sistemas de información de hipermedia distribuidos y colaborativos, cuyos usos son
diversos y entre los que se encuentra la transferencia de hipermedia. Esta transferencia
se lleva a cabo a través de métodos de petición, códigos de error y encabezados.
(Fielding et al. 1999).
La hipermedia puede ser definida como la materia de la que se compone la web
(Nadareishvili, 2013). Explicado de una forma más específica, el concepto de hipermedia
se refiere a una extensión del término hipertexto (que a su vez se refiere a un texto que
referencia a un documento basado en texto a través de un link de navegación en la World
WIde Web), que incluye a diferentes formatos de información como posibles
contenedores de links (Massé, 2011). Entre estos formatos pueden mencionarse:
imágenes, videos, entre otros.
Dos de los términos más ampliamente utilizados al hablar del protocolo HTTP/1.1
son: recursos y Uniform Resource Identifier, URI de ahora en adelante. Un recurso se
refiere a cualquier objeto de data o servicio que puede ser accedido mediante un método
de petición de HTTP. Para poder acceder a estos recursos, es necesario que se provea
una localización abstracta en la que se localizan. Esta ubicación se representa por el URI,
que es un conjunto de caracteres con un formato específico (Fielding et al. 1999). Cabe
destacar que estos recursos no son las entidades que representan, sino que puede ser
entendido como una traducción de dicha entidad. Esto significa que, si bien una entidad
puede cambiar en el tiempo, un recurso no cambia de la misma manera, pues solo se
encarga de traducir el estado de dicha entidad al momento en que se acceda a él
(Fielding, 2000)
Los principales métodos de petición al servidor que maneja el protocolo, según
Fielding et. al, son:
● OPTIONS: petición acerca de las opciones de comunicación que posee el
servidor, de forma que el cliente pueda identificar los recursos a los que puede acceder,
los requerimientos para obtener dichos recursos y las capacidades del servidor.
9
● GET: busca recopilar la información que se guarda en el respectivo URI al que se
hace esta petición. Esta operación puede desencadenar procesos generadores de
información por parte del servidor, que son invisibles al cliente.
● HEAD: es idéntico al método GET, con la diferencia que la respuesta solo provee
la metadata asociada a la data que se envía con el método GET.
● POST: es una petición para que el servidor acepte la data que se envía, para que
sea catalogada como subordinada del recurso que se identifica por el respectivo URI.
● PUT: se utiliza para realizar la petición de que el servidor utilice la data provista
para colocarla bajo el URI provisto. Si existiese ya un recurso en este URI, el servidor
podría considerar reemplazarlo.
● DELETE: busca eliminar el recurso que se encuentra en el URI provisto.
No se busca en esta sección profundizar en las diversas características del protocolo
explicado, más si es de vital importancia establecer que este será el utilizado para la
comunicación que se llevará a cabo entre las API's desarrolladas y el sitio web que se
diseñó para ejecutar la experimentación, planteada en el capítulo III.
Antes de poder definir los elementos que rodean a la comunicación que se lleva a
cabo entre un sitio web y una API, hay que poder discernir la diferencia existente entre
un estilo arquitectónico y una tecnología. Esto debido a que, como se verá más adelante,
los mecanismos arquitectónicos que se buscaron evaluar en el presente trabajo de
investigación pueden categorizarse cada uno bajo uno de estos conceptos
respectivamente.
Un estilo arquitectónico puede ser definido como un conjunto de: componentes y sus
responsabilidades; conectores entre componentes y su comunicación, cooperación,
coordinación, entre otros; restricciones que definen cómo se integran los componentes
para formar el sistema; modelos que permiten comprender las propiedades de un
sistema general en función de las propiedades conocidas de las partes que lo integran
(Gutiérrez, 2011).
10
De hecho, cuando se mencionó la arquitectura de cliente-servidor, se estaba
haciendo referencia a un estilo arquitectónico de software. Se definieron en él los
componentes participantes, sus responsabilidades, los conectores y las restricciones que
deben seguirse, todo de una forma resumida para la mejor comprensión del mismo.
Cuando se hace referencia a una tecnología, lo que se busca describir es la
implementación de un software que sigue las características o los lineamientos que
fueron establecidos por un estilo arquitectónico específico. Sin embargo, una tecnología
no tiene la obligación de seguir un estilo arquitectónico específico, pues puede
construirse de forma libre o siguiendo los lineamientos de cierto estilo arquitectónico, sin
ceñirse a todas las restricciones que el mismo impone. Lo anterior puede verse reflejado
en la dura crítica que realiza Fielding (2008) en su blog, en el que expresa su descontento
con distintas API’s creadas bajo la premisa de seguir el estilo arquitectónico generado
por él: REST, cuando en realidad no cumplen con las restricciones obligatorias.
1
Endpoint: URI asociado con un recurso, al que se le pueden realizar distintas operaciones HTTP
definidas por la API, como lo pueden ser: GET, PUT, POST, DELETE, entre otras.
11
más de la necesaria, lo que implica un mayor costo en cuanto a la transferencia de datos
y el manejo de los mismos en memoria. Esto puede generar problemas de rendimiento a
escalas mayores y generar un impacto negativo en el uso de aplicaciones.
Ambos conceptos son necesarios para poder llevar a cabo la investigación presente
debido a su alta importancia al momento de determinar el rendimiento y funcionamiento
de las API’s.
12
sitios web que les dan uso y a que hacen uso de HTTP como protocolo de comunicación
con estos sitios. Este fue el caso desde el año 2000, pues debido a su amplio éxito,
REST se utilizó como estilo arquitectónico para llevar a cabo la comunicación HTTP entre
una API y un sitio web.
Estas restricciones que definen el estilo REST, establecidas por su creador Roy
Fielding, son:
● Cliente-servidor.
● Sin Estado.
● Cache.
● Interfaz uniforme.
● Sistema en capas.
● Código por demanda.
II.2.1.1 Cliente-Servidor
La primera restricción que Fielding estableció, fue que el sistema siguiera una
arquitectura del tipo cliente-servidor. Esta arquitectura fue ya explicada en la sección
II.1.2.
13
II.2.1.3 Caché
Es otra restricción que modifica directamente a la arquitectura cliente-servidor, pues
establece que el servidor tendrá la responsabilidad de etiquetar cada una de sus
respuestas como Cachable o no. Esta etiqueta indica a un componente intermediario,
denominado Caché, si las respuestas enviadas al cliente pueden ser almacenadas en
este componente. De esta forma, el cache verifica cada petición que el cliente realiza al
servidor y, de poseer ya la respuesta de dicha petición, la envía al cliente sin tener que
contactar al servidor. Esta restricción permite una mejora en el rendimiento de la
comunicación entre el cliente y el servidor, mejora que puede ser perceptible incluso por
el usuario (Fielding, 2000 y Massé, 2011).
14
II.2.1.4.2 Representación
Cada uno de los componentes manipula representaciones de los recursos, mas no
manipulan los recursos como tal. Esto significa que un recurso puede ser representado
de diferentes formas, permitiendo así diferentes interacciones sobre un recurso, sin
jamás cambiar su identificador (Massé, 2011).
El formato de cada una de las representaciones se conoce como media. La media
puede describirse como un conjunto de datos que vienen acompañados de una metadata
que indica la forma en la que deben interpretarse estos datos. La metadata puede ser
singular, cuando solo representan un solo recurso, o puede ser compuesta, cuando
representan diferentes recursos (Fielding, 2000).
15
II.2.1.5 Sistema en capas
En cualquier sistema que desee seguir el estilo arquitectónico de REST, debe
existir una separación del mismo en distintas capas jerárquicas, de forma que cada
una de las capas utilice los servicios de la capa anterior a ella para proporcionar
otros servicios a la capa posterior. Esto de por sí es un estilo puro, pero cuando se
especifica en un sistema con todas las restricciones anteriores, se trata de introducir
a las ya existentes capas de cliente-servidor, nuevas capas intermedias que son
independientes en su funcionamiento y que asisten al sistema en diferentes
funciones como lo son: seguridad, el uso del caché, entre otros. Algunas capas
comunes que se utilizan son: los gateways, los proxies y los cachés intermediarios
(Fielding, 2000 y Massé, 2011).
II.2.2 GraphQL
16
Esta tecnología difiere de la RESTful API estándar, es decir, de la API que utiliza el
estilo REST, en varios aspectos claves. A continuación, se buscará explicar las
características principales de esta tecnología, según Eizinger, T. (2017).
II.2.2.1 Types
Los Types, o Tipos, son el equivalente en GraphQL a los objetos en la capa de datos
de la aplicación. Esto quiere decir que representan la información de una forma clara,
para poder interactuar directamente con la estructura de los datos a través de la API y
sus endpoints definidos.
Estos tipos se relacionan entre sí y poseen campos diferentes entre sí que los
componen. Las relaciones pueden observarse si existe un tipo que posee por campo otro
tipo. Un ejemplo de esto puede observarse en la figura 2, que se explicará más
claramente con el concepto de Esquema.
Existen distintas clases de tipos que se pueden utilizar:
● Tipos Básicos: generalmente usados como campos dentro de los tipos más
complejos, son: String, Int, Float, Boolean y ID.
● Tipos Objeto: son los tipos con mayor complejidad y comportamiento propio,
definido bajo los requerimientos que los desarrolladores identifican para proporcionar
flexibilidad a la API.
● Tipos Input: se utilizan para poder enviar parámetros más complejos que campos
básicos, tales como objetos completos, hacia la API para realizar cualquier operación
que haya sido definida anteriormente.
II.2.2.2 Esquema
17
Esto se profundizará posteriormente en la sección II.2.2.3 de esta tecnología, donde se
cubre el tema de los queries en GraphQL.
18
En el esquema se definen otros dos elementos de vital importancia para la tecnología
GraphQL: query y mutation. Sobre esto se hará referencia en las siguientes secciones.
II.2.2.3 Queries
19
Figura 3. Ejemplo de un Query.
II.2.2.4 Mutations
20
Figura 4. Ejemplo de una Mutation.
II.2.2.5 Resolvers
Los resolvers son otra parte esencial de GraphQL. Estos son los encargados de dar
sentido a la capa de abstracción que da GraphQL al resto de la estructura del
denominado backend. De tal manera, los resolvers unen el schema con la capa de datos,
dígase una base de datos, utilizando funciones que son llamadas dependiendo de lo que
especifica una llamada.
Sin embargo, los únicos resolvers que son necesarios declarar de forma explícita son
aquellos que deban ejecutar llamadas a Types complejos, ya que las librerías asociadas
se encargan de unificar las propiedades básicas. De esta forma, GraphQL es capaz de
resolver las peticiones a objetos anidados en otros objetos en la estructura señalada en
el esquema. Esto es necesario ya que, usualmente, la base de datos no almacenará los
objetos anidados; sino que los objetos tendrán un campo en el cual exista un identificador
que señale a otra entidad.
21
II.3.2 ISO 9126 y 25010
Los softwares son cada vez más utilizados para realizar tareas tanto personales
como profesionales, y por ello es necesario que la calidad de estos sea lo suficientemente
alta como para garantizar un funcionamiento y resultados cada vez mejores. Por tal razón
es necesario la utilización de estándares permitan determinar los niveles de calidad del
software.
La Organización Mundial de Normalización (ISO) y la Comisión Electrotécnica
Internacional (IEC), que son compañías hermanas según lo descrito por IEC (2018), han
desarrollado múltiples estándares de calidad en distintas áreas de interés común. Dichos
estándares poseen una amplia aprobación debido a que múltiples comités y grupos
internacionales forman parte de estas asociaciones: según ISO (2018) 161 naciones son
miembros, a través de sus propias organizaciones, de esta alianza global para la
estandarización y la calidad. De tal forma, se justifica el uso de estos en el desarrollo de
la evaluación en este trabajo utilizando los estándares de calidad de software, ISO 9126
e ISO/IEC 25010.
Según el documento oficial de ISO, 9126-3 (2002), las métricas de eficiencia interna
se usan para predecir la eficiencia del comportamiento del producto de software durante
pruebas y operaciones. El objetivo de esto sería poder crear un marco comparativo con
base en las predicciones de eficiencia mencionadas.
De forma similar, esta característica también se divide en otras subcaracterísticas
con las cuales podrá ser evaluada la característica a cabalidad. Estas son las siguientes:
● Comportamiento del tiempo: acota a ciertos atributos con los cuales es posible
hacer predicciones en cuanto al comportamiento del tiempo.
● Utilización de recursos: se refiere a la utilización de recursos de hardware por la
computadora durante las pruebas y operaciones del software en cuestión.
● Cumplimiento de la eficiencia: hace referencia a los atributos para evaluar la
capacidad de un software para cumplir con estándares, regulaciones y convenciones
22
II.3.2.2 Eficiencia de desempeño (ISO/IEC 25010)
II.4.1 Node.js
2
Throughput: medida que determina la cantidad de operaciones o tareas que un software puede realizar
en una unidad de tiempo específica.
23
Chrome. Este permite las operaciones de E/S sin bloqueo y orientado a eventos, lo cual
hace al software más eficiente y liviano.
Este también cuenta con Node Packet Manager (2018), de ahora en adelante
npm, uno de los ecosistemas de paquetes más grandes del mundo, para el ambiente de
paquetes de Node.js.
II.4.2 Express
Express (2017) es un framework web para Node.js que se caracteriza por ser
liviano y minimalista. Este pone a disposición herramientas necesarias para el desarrollo,
proporcionando una estructura básica con utilidades de HTTP y otras características
fundamentales para aplicaciones web; por lo cual se pudo construir a través del mismo
la estructura base para ambos mecanismos arquitectónicos a evaluar.
II.4.3 Angular 5
24
Estas herramientas debían ser capaces de realizar las siguientes tareas para ejecutar
una evaluación cabal y exitosa:
● Medir el tamaño de los payloads3 recibidos, en relación con la información
esperada y/o deseada.
● Medir tiempo de respuesta del servidor, medido desde el momento en que el frontend
realiza la petición hasta el momento en que la respuesta del backend es recibida.
II.4.4.1 Sizeof
3
Payload: respuesta que el servidor envía al cliente después que el último realiza una petición. Posee la
data requerida y su metadata correspondiente, además de los elementos requeridos por el protocolo
HTTP, como por ejemplo, los encabezados.
25
26
Capitulo III. Marco Metodológico
27
puede ser, por ejemplificar, la cantidad de llamadas a una misma función de forma
paralela que puede procesar sin colapsar.
En vista de lo anterior, y basándose en el documento de las organizaciones ISO/IEC
(2002) Software engineering –Product quality – Part 3: Internal metrics, se diseñó un
marco comparativo, que posee las métricas a utilizar para medir las áreas de:
comportamiento temporal, utilización de recursos y capacidad, que serán consideradas
como las variables que deben estudiarse. Cabe acotar que, debido a la carencia de
metas de rendimiento, por su indisponibilidad de forma gratuita, no se tomó en cuenta la
característica de cumplimiento de la eficiencia planteada en el estándar ISO 9126. Dicho
marco puede observarse en las tablas 1, 2 y 3.
Para la completa comprensión de las tablas 1, 2 y 3 debe definirse el concepto de
llamada atómica. En sistemas operativos, se definen las operaciones atómicas como
aquellas en las que, en un espacio de memoria compartido para varios hilos, ningún hilo
puede ver dicha operación a medias en su ejecución, es decir, solo puede observarse un
cambio al momento que se termina dicha operación (Preshing, 2013), indicando esto que
estas operaciones son las más básicas que pueden realizarse en dicho sistema
operativo. Tomando esta definición, se decidió acuñar el término de llamada atómica,
que se entiende por la llamada más básica que se puede realizar a una API. En el caso
de una API RESTful, esto equivale a cualquier operación que se hace a un único
endpoint, sea la misma un GET, PUT, POST, entre otros; en el caso de una API
desarrollada con GraphQL, el término se aplica a llamadas que no requieren de la
resolución de campos complejos de un recurso por parte de la tecnología para retornar
una respuesta, o dicho de otra manera, de la ejecución de queries anidados.
28
Tabla 1: Sección de comportamiento temporal del marco comparativo utilizado en
las API’s desarrolladas.
llega la
respuesta
deseada.
29
Tabla 2: Sección de utilización de recursos del marco comparativo utilizado en las
API's desarrolladas.
30
Tabla 3: Final de sección de utilización de memoria y sección de capacidad del
software del marco comparativo utilizado en las API’s desarrolladas.
de recibidas.
llamadas
realizadas
31
III.3 Hipótesis planteada
III.4.1 Tamaño
El primero de estos, el tamaño, se refiere al tamaño del paquete recibido de ambas
API’s. En este caso se utilizó una librería de npm, llamada sizeof, que contiene funciones
para la medición de variables u objetos. Un ejemplo de estas funciones se puede
observar en la figura 5 (las líneas resaltadas).
De forma más específica, el tamaño se mide con dos objetivos distintos: determinar
el peso del objeto recibido y el peso considerado útil. Para lo primero solo se mide el
tamaño del paquete recibido completo, con la metadata que este traiga y todos los datos
contenidos. Mientras que para medir peso útil se realizó un proceso especial, en el que
32
se selecciona de forma aleatoria los campos a considerar como útil y se miden
únicamente estos, sin incluir metadata.
III.4.2 Tiempo
La segunda sección de la data recolectada es el tiempo. Para esto se utilizó el objeto
de javascript Date para generar marcas de tiempo en distintos momentos y determinar
la duración de diferentes periodos de tiempo en milisegundos, esto se ejemplifica en la
figura 6 en las líneas resaltadas. De forma similar al tamaño, el tiempo se midió con dos
objetivos distintos: determinar el tiempo de respuesta de una petición única y el tiempo
de respuesta de múltiples peticiones.
En primer lugar, el tiempo de respuesta se midió haciendo una marca de tiempo
cuando se hace la petición, otra marca cuando llega la respuesta y se hizo una resta
para determinar cuántos milisegundos tomó en llegar desde el momento en que se emitió
la petición. Luego, para determinar el tiempo completo de la prueba, se realizó una marca
de tiempo al inicio de la prueba y se comparó con otra marca temporal realizada al
momento que llega cada respuesta; de tal manera se obtuvo el tiempo en el cual se
recibe la respuesta, teniendo en cuenta que el inicio de la prueba marca el milisegundo
0.
33
Figura 6. Extracto de Código de Frontend donde se resaltan las líneas donde se
generan las marcas de tiempo para las mediciones.
III.4.3 Peticiones
Las peticiones se midieron de forma que cada llamada a una API se consideraba
una petición. Sin embargo, solo se consideraron las peticiones exitosas, es decir, de las
cuales se haya obtenido una respuesta. De tal manera, cada vez que se recibía
información de una API, se tomaba la petición como exitosa y se sumaba a un contador
determinado para la prueba. En las figuras 5 y 6, se almacena el número de peticiones
en el contador totalLlamadas en el vector tableData.
34
Figura 7. Extracto de código utilizado para la prueba de rendimiento.
35
III.5.2 Acercamiento de la investigación
Como se definió anteriormente, GraphQL y REST son dos mecanismos
arquitectónicos que se encuentran en niveles diferentes, puesto que GraphQL es una
tecnología y REST es un estilo arquitectónico. Según Eizinger (2017), para hacer una
comparación de estos dos mecanismos existen tres posibles acercamientos:
1. Generalizar GraphQL y subirlo al nivel de un estilo arquitectónico.
2. Especializar REST, es decir, crear una tecnología que siga las restricciones del
estilo perfectamente.
3. Utilizar únicamente los principios arquitectónicos de cada mecanismo para su
comparación.
En el presente trabajo, se decidió utilizar el segundo acercamiento, lo que implica
entonces que la investigación fue del tipo experimental. Para mantener un control del
ambiente en el que se realizaba el experimento, ambas API’s fueron construidas
utilizando NodeJS como entorno de ejecución y utilizando Express.js como framework
de desarrollo. Además, ambas fueron utilizadas por el mismo frontend y medidas con el
mismo software, definido ya en la sección de instrumentos de recolección. De la misma
forma, utilizaron la misma base de datos creada en MongoDB, con el mismo paquete de
node siendo utilizado para la comunicación con la misma. Ambas API’s fueron corridas
de forma local, al igual que las bases de datos utilizadas, junto con la página web. La
computadora que fue utilizada fue una Aspire V 15 Nitro marca Acer, cuyas
especificaciones técnicas pueden ser observadas en la tabla 4.
36
Tabla 4: Datos de fabricante y especificaciones técnicas de la computadora en
donde se realizaron las pruebas.
Especificaciones
Fabricante Acer
Especificaciones Técnicas
37
III.5.3.3 Diseño de las API’s
En esta fase, se llevó a cabo la programación de cada una de las API’s que se
utilizarían para medir el rendimiento de GraphQL y de una implementación fiel del estilo
REST. Para poder desarrollarlas, sin embargo, tuvo primero que elegirse un caso de
estudio que aplicar evidenciar al máximo las debilidades y fortalezas de cada uno de los
mecanismos arquitectónicos.
El caso de estudio seleccionado consiste en una librería virtual, la cual tiene 3
entidades: Autor, Libro y Género. Estas están construidas de manera que se relacionan
en doble sentido unas con otras, de forma que se puede llegar a cualquiera de ellas
desde cualquier otra; esto permite una flexibilidad que hace a este caso de estudio uno
completamente general. Para mayor especificidad de cómo están compuestos los
modelos de los recursos, se expone en la figura 8 un extracto de código utilizado en la
elaboración de las API’s.
38
poseerán los escenarios de pruebas necesarios para poder aplicar las métricas definidas
de una manera completa e imparcial, logrando cubrir las particularidades de cada uno de
los mecanismos arquitectónicos, explicadas en el capítulo 2, en la sección II.2.
39
40
Capítulo IV. Análisis de Resultados
Como segundo objetivo del estudio, se pretendió: Diseñar un caso de estudio que
permita comparar los mecanismos escogidos. Para poder evaluar correctamente los
mecanismos arquitectónicos, debía generarse un caso de estudio que permitiera explotar
las debilidades y fortalezas, desde el punto de vista de rendimiento, de cada uno. Este
caso de estudio fue ya explicado en el capítulo III del presente estudio, en la sección
III.5.3.3, en la que se explicó que se utilizaría una librería virtual que daría uso a tres
modelos de información: autores, libros y géneros. El motivo de utilización de este caso
de estudio fue explicado de igual forma en la sección señalada.
41
IV.3 Desarrollo de las API’s y de su web consumidora
42
considera que el mismo es representativo puesto que la configuración para los demás
modelos es la misma, variando únicamente la data que se recibe y envía para adaptarse
a cada uno de los modelos.
43
Figura 10. Extracto de Código de la API que representó al estilo REST, sección de
endpoints, segunda parte.
44
Figura 11. Extracto de Código de la API que representó al estilo REST, sección de
endpoints, tercera parte.
IV.3.1.3 Caché
Una representación de REST debe, necesariamente y como fue expuesto en el
capítulo II del escrito, hacer uso del caché como un middleware o intermediario que
permita evitar el llamado a sistemas o recursos externos, como lo es la base de datos.
Para esto, se implementó la función que puede observarse en la figura 12.
45
Figura 12. Extracto de Código de la API que representó al estilo REST, función de
caché.
46
siempre, es decir, solo fue implementada en aquellos endpoints que tuviesen por
operador el método GET. Esta aplicación puede ser observada en la figura 13.
Figura 13. Extracto de Código de la API que representó al estilo REST, ejemplo de
implementación de caché.
IV.3.1.3.2 Representación
Esta restricción implica que cada uno de los endpoints envía data que solo
representa al recurso que fue pedido, pero no envía dicho recurso como tal. Esto posee
dos implicaciones: en primer lugar, que la data puede venir en diferentes formatos no
necesariamente ligados al recurso como tal y en segundo lugar, las modificaciones
hechas a la data fuera del servidor no se aplican al recurso al que representan. La figura
47
14 demuestra el formato en el que la data es manejada en la API, sin embargo, este
formato podría cambiar para tener data diferente o para manipular la data que proviene
del recurso y generar otros campos de ser necesario en un futuro. Además, como puede
verse en las figuras 9, 10 y 11, la data enviada en cualquiera de los métodos proviene
de un resultado de una búsqueda en la base de datos, que realmente es un conjunto de
datos que representa al recurso del que se trata y no el conjunto propiamente.
48
Figura 15. Respuesta recibida de un query realizado a la API representante de REST.
49
IV.3.2 API GraphQL
Esta API fue construida usando la tecnología de GraphQL, junto con un paquete
instalado a través de npm llamado express-graphql, que se utilizó para poder
comunicarse con la API a través del protocolo HTTP, aprovechando el framework
Express y sus facilidades para ello. A continuación, para demostrar la implementación
realizada, se expondrá el esquema utilizado y sus resolvers correspondientes.
IV.3.2.1 Esquema
Basado en los modelos planteados en la figura 7, se creó el esquema expuesto
en las figuras 16, 17 y 18.
50
En la figura 16, pueden observarse los queries y mutations que fueron planteados
para la API realizada. Estos corresponden a una estructura Create, Read, Update, Delete
o CRUD básica, es decir, se crearon las operaciones necesarias para poder crear, leer,
actualizar o borrar cualquiera de los recursos.
Figura 17. Esquema realizado en GraphQL, types e inputs para los libros y los
autores.
51
Figura 18. Esquema realizado en GraphQL, types e inputs para los géneros.
IV.3.2.2 Resolvers
Para poder llevar a cabo los queries, mutations y resolución de campos de los
types en los que la búsqueda a la base de datos no retorna el objeto que debería, como
por ejemplo cuando en la base de datos existe para un libro el ID de su autor, mas no el
objeto autor como tal. Esto se ve reflejado en las figuras 19, 20 y 21.
52
Figura 19. Resolvers para los campos complejos de los types.
53
Figura 21. Resolvers para las mutations.
Puede notarse que los resolvers son utilizados únicamente para hacer las
operaciones respectivas necesarias en la base de datos. Esto se hace a través de los
54
llamados repositorios; esta separación fue realizada para demostrar que podría
interactuarse con cualquier repositorio de datos y la estructura se mantendría intacta.
Como se puede ver en la figura 22, los resultados de las pruebas son mostrados en
las tablas que se exponen en el sitio web y que dichas pruebas se realizan bajo los
parámetros seleccionados en la parte superior. De tal manera se pueden realizar
distintas pruebas con distintos parámetros.
Los parámetros mencionados son: Tipo de query, donde se selecciona si los queries
serán atómicos, complejos o mixtos y de forma aleatoria o únicos; luego, el tiempo
mínimo por el que se realizará la prueba, en milisegundos; y por último la mínima
cantidad de iteraciones que se realizarán. En caso de llenar ambos campos, se realizará
la prueba hasta que ambas condiciones se cumplan. El parámetro prueba señaliza qué
prueba se está realizando.
55
Las funciones diseñadas para hacer las peticiones y medir las respuestas pueden
observarse en la figura 23 y 24. La primera muestra un ejemplo de estas funciones para
el caso de la medición de las respuestas de la API de GraphQL, mientras que la segunda
es la función con el mismo propósito para el caso de REST.
Figura 23. Ejemplo de función para hacer una petición y medir respuesta, caso
GraphQL.
Figura 24. Ejemplo de función para hacer una petición y medir respuesta, caso
REST.
56
Como se puede observar en el código expuesto en las figuras 23 y 24, ambas
peticiones se realizan por http. En el caso de GraphQL, se utiliza una llamada POST
debido a que el string que representa el query se envía como parte del cuerpo del
mensaje, para lo cual se suelen hacer llamadas de este tipo. Sin embargo, en REST solo
es necesario hacer una petición GET ya que los URI tienen programadas que
operaciones es necesario realizar para obtener el recurso pedido dependiendo del tipo
de llamada que se realice.
Para terminar con esta sección, cabe acotar que las mediciones realizadas en los
códigos expuestos en las figuras 23 y 24 siguen el mismo esquema en ambos casos, lo
cual verifica que la forma en la que se están midiendo es la misma y se evita cualquier
error que pueda venir de diferencias en la toma de datos.
IV.4 Mediciones
57
last_name
birth_date
birth_place
death_date
death_place
age
}
}
● Para REST, se realizó una petición GET al siguiente endpoint:
http://localhost:3001/api/authors/:ID.
58
Tabla 5: Resultado de las mediciones para tiempo de respuesta, GraphQL.
59
Tabla 6: Resultado de las mediciones para tiempo de respuesta, REST
Como puede observarse, las medias junto con sus errores no se solapan, por lo
que es posible determinar que la API REST es más veloz al dar respuesta para peticiones
de queries atómicas. Esto, en principio, corrobora la hipótesis planteada y la explicación
podría venir por el uso del caché en REST, que no existe en GraphQL, sin embargo esto
se vería reflejado en la tabla mediante una duración significativamente mayor en la
primera petición, con respecto a las demás, hecho que no ocurre, debido a que la
operación es tan simple (por no realizar peticiones a otros sistemas a través de internet
y por ser una única lectura a la base de datos) que tiene una duración parecida a la
utilización del caché. Esto indica que la explicación efectivamente viene dada debido al
tiempo que toma GraphQL en resolver cada uno de los campos requeridos, verificando
que no existan campos complejos que deban poseer operaciones adicionales planteadas
en los resolvers.
60
IV.4.2 Rendimiento o throughput
Para llevar a cabo la prueba en relación a esta métrica se realizaron queries en
secuencia de forma síncrona, es decir que se realizaron peticiones a los respectivos
backend y se esperó la recepción de la respuesta para realizar la siguiente petición.
Para ello se realizaron los siguientes queries:
● Para GraphQL, se utilizó el query:
query{
author(id: ID){
_id
given_name
middle_name
last_name
birth_date
birth_place
death_date
death_place
age
}
}
● Para REST, se realizó una petición GET al siguiente endpoint:
http://localhost:3001/api/authors/:ID.
El parámetro ID se seleccionó de forma aleatoria por el software de medición para
generar peticiones distintas al mismo recurso. Tales peticiones realizadas son
consideradas atómicas bajo la definición expuesta en la sección IV.4.1.
Bajo lo definido anteriormente, se realizó la prueba de forma que se generaron
peticiones hasta cumplido un segundo de tiempo y se midió únicamente la cantidad de
respuestas recibidas. Los resultados obtenidos fueron los expuestos en las tablas 7 y 8
para ambas API’s.
61
Tabla 7: Resultado de las mediciones para rendimiento, GraphQL.
62
Tabla 8: Resultado de las mediciones para rendimiento, REST.
Como puede observarse, los errores no causan que los resultados se intersecten y,
por lo tanto, se puede inferir que GraphQL tiene una mayor capacidad de respuesta por
unidad de tiempo. Sin embargo, este resultado no es cónsono con el obtenido en la prueba
de tiempo, en la cual se determinó que REST tiene un periodo de respuesta más corto.
No obstante, se consideró que la causa de esto podía ser que, puesto que la prueba fue
realizada con una función recursiva, la computadora presentó problemas de rendimiento
debido al acumulamiento de respuestas; y, debido a que las respuestas de REST son
considerablemente más pesadas, el sistema se ve mayormente afectado por las mismas.
63
book(id: ID){
_id
title
edition
year
}
}
● Para REST, se realizó una petición GET al siguiente endpoint:
http://localhost:3001/api/books/:ID.
En ambos casos, el parámetro ID fue generado de forma aleatoria por el software de
medición, cambiando para cada una de las llamadas, para asegurar así que no se
estuviese considerando únicamente el tamaño de un payload específico, pero siendo el
mismo ID para cada query por cada muestra tomada.
Nuevamente, los queries son considerados atómicos por las mismas razones
expuestas anteriormente en la sección IV.4.1.
Las tablas 9 y 10 reflejan los resultados de las mediciones realizadas, para cada una
de las API’s respectivamente, con su respectiva media, desviación estándar y error.
64
Tabla 9: Resultado de las mediciones para utilización de memoria, GraphQL.
65
Tabla 10: Resultado de las mediciones para utilización de memoria, REST.
Debido a que las medias con sus errores no se solapan, es posible determinar que
GraphQL tiene una ventaja en el área de utilización de memoria. Esto ocurre debido dos
factores: en primer lugar, la restricción que obliga a la API REST a ser auto-descriptiva,
lo que implica que cada uno de las respuestas que da posee su propio mensaje
personalizado de status, además de la respuesta; en segundo lugar, la restricción que
obliga a la API REST a poseer los links relevantes al recurso, lo que representa al menos
un campo más en la respuesta.
66
se realiza normalmente a través de los URI, pero al no poseer GraphQL endpoints, esto
no es posible de una forma natural.
Debido a lo anterior, la ventaja en este campo para REST es clara.
IV.4.5 Overfetching
Para llevar a cabo la medición de esta métrica, se realizaron queries al recurso
autor, utilizando siempre un ID aleatorio y definiendo de antemano, también de forma
aleatoria, un conjunto de campos que fuesen considerados importantes. Esta selección
aleatoria fue realizada por el software desarrollado. Luego de esto, se midió el tamaño
que representaban estos campos seleccionados y se comparó con el tamaño total del
paquete recibido.
Las tablas 11 y 12 reflejan los resultados de las mediciones realizadas, para cada
una de las API's respectivamente, con su respectiva media, desviación estándar y error.
67
Fuente: elaboración propia
68
Debido a que las medias con sus errores no se solapan, es posible determinar que
GraphQL tiene una ventaja en el área de overfetching. Esto ocurre debido a que, en
primer lugar, fue determinado anteriormente que las respuestas de la API en GraphQL
son significativamente menores en tamaño que las respuestas de la API REST; y, en
segundo lugar y con mayor importancia, GraphQL permite personalizar a través de los
queries los campos de la respuesta que envíe la API.
IV.4.6 Underfetching
Para llevar a cabo la medición de esta métrica, se definieron campos de forma
aleatoria que, si bien guardaban relación entre si, solo podían resolverse a través de
queries complejos, es decir, no atómicos, que por lo tanto incluían al menos dos recursos
de modelos diferentes; un ejemplo de esto podría ser requerir un libro con todas sus
características, junto con el nombre y apellido de su autor. Esta selección de
requerimientos aleatoria fue realizada por el software desarrollado. Luego de esto, se
midió la cantidad de llamadas que fue necesario hacer a cada API para poder cumplir
con los requerimientos planteados.
Las tablas 13 y 14 reflejan los resultados de las mediciones realizadas, para cada
una de las API’s respectivamente, con su respectiva media, desviación estándar y error.
69
Tabla 13: Resultado de las mediciones para underfetching, GraphQL.
70
Debido a que las medias con sus errores no se solapan, es posible determinar que
GraphQL tiene una ventaja en el área de underfetching. Esto ocurre debido a que
GraphQL permite realizar queries anidados para obtener aquellos recursos que estén
relacionados al recurso que se esté pidiendo, mientras que la API REST necesita realizar
peticiones a diferentes endpoints para poder reunir todos los requerimientos planteados.
IV.4.7 Capacidad
Esta prueba fue realizada utilizando queries atómicos, realizando simultáneamente
grandes cantidades de pruebas. Inicialmente, se intentó realizar 100 pruebas en cada
API, pero se lograban responder todas las peticiones; debido a esto, se subió el número
de pruebas en varias ocasiones, pero en todas ellas, ambas API’s lograban responder
satisfactoriamente.
Observando lo anterior, se llegó a la conclusión de que ambas API’s tienen la
capacidad de responder a todas las llamadas que el hardware de la computadora que
ejecuta el backend permita. Por esto, ninguna de ellas obtiene ventaja en esta métrica.
71
Tabla 15: Resultado de las mediciones para velocidad bajo estrés, GraphQL.
Tabla 16: Resultado de las mediciones para velocidad bajo estrés, REST.
72
Debido a que las medias con sus errores no se solapan, es posible determinar que
REST tiene una ventaja en el área de velocidad bajo estrés. Esto ocurre debido a que,
como se ha observado en anteriores pruebas, la API REST resuelve las peticiones de
forma más veloz que la API en GraphQL. Nuevamente, esto se debe a la verificación que
GraphQL realiza en cada una de las peticiones, en las que observa los campos y, si
alguno es complejo en el sentido de que posee una forma de resolverlo a través de sus
resolvers, sigue el código que en ellos se encuentra. Esta característica no cambia bajo
el estrés y es un indicio de que ciertamente la forma en la que los datos fueron recogidos
para determinar la métrica de rendimiento pudo haber afectado a los resultados.
Con los resultados anteriormente mostrados y analizados, se considera cumplido el
objetivo de: Caracterizar las ventajas y desventajas de los dos mecanismos estudiados
en relación al caso de estudio.
73
74
Capítulo V. Conclusiones y Recomendaciones
75
Como recomendaciones para futuros trabajos:
● Se insta a evaluar ambos mecanismos desde otros puntos de vista fuera del
rendimiento, como podría serlo la compatibilidad, la usabilidad, entre otros.
● Se insta a ahondar la investigación mediante el uso de un entorno en línea y con
una mayor interacción con otros sistemas, de forma que se evalúe el impacto que puede
tener el caché en las métricas de comportamiento temporal.
76
Referencias Bibliográficas
Byron, L. (2015) GraphQL: A data query language. [Artículo oficial de Facebook acerca
de GraphQL]. Recuperado en
https://code.facebook.com/posts/1691455094417024/graphql-a-data-query-
language/. El 16 de noviembre del 2017.
Grigorik, I. (2013) High Performance Browser Networking: What Every Web Developer
Should Know About Networking and Browser Performance. Sebastopol,
California, Estados Unidos: O’Reilly.
77
Held, G. (2000). Server management. Boca Raton, Florida, Estados Unidos: Auerbach.
How To GraphQL (2018). GraphQL is the better REST. [Artículo informativo en línea]
Recuperado de: https://www.howtographql.com/basics/1-graphql-is-the-better-
rest/
ISO / IEC (2002). Software engineering –Product quality – Part 3: Internal metrics. (TR
9126-3). [Documento no publicado en línea]
Lane, K. (2013). API 101. [Ensayo introductorio sobre API’s] Recuperado de:
https://s3.amazonaws.com/kinlane-productions/whitepapers/API+Evangelist+-
+API+101.pdf
Massé, M. (2011). REST API Design Rulebook: Designing Consistent RESTful Web
Service Interfaces. Sebastopol, California, Estados Unidos: O’Reilly.
78
Npm, Inc. (2014). Sizeof. [Documentación de paquete Sizeof en línea]. Recuperado de:
https://www.npmjs.com/package/sizeof
Preshing, J. (18 de junio de 2013) Atomic vs. Non-Atomic Operations. [Blog en línea].
Recuperado de: http://preshing.com/20130618/atomic-vs-non-atomic-
operations/
ReadMe (15 de noviembre de 2016). The History of REST APIs. [Artículo de blog en
línea]. Recuperado de: https://blog.readme.io/the-history-of-rest-apis/
79