GraphQL Vs REST

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/329155233
GraphQL vs REST: una comparación desde la perspectiva de eﬁciencia de

desempeño.
Presentation · November 2018

DOI: 10.13140/RG.2.2.25221.19680
CITATIONS READS
0 61
3 authors, including:
Christian Alfredo Guillen-Drija Reynaldo Quintero

Universidad Metropolitana, UNIMET Universidad Metropolitana, UNIMET
7 PUBLICATIONS 2 CITATIONS 1 PUBLICATION 0 CITATIONS
SEE PROFILE SEE PROFILE
All content following this page was uploaded by Reynaldo Quintero on 09 December 2018.
The user has requested enhancement of the downloaded file.

Universidad Metropolitana
Facultad de Ingeniería
Escuela de Ingeniería de Sistemas
GraphQL vs REST: una comparación de rendimiento a nivel

práctico.
Asher Kleiman.
Reynaldo Quintero.
Tutor: Christian Guillén
Caracas, Junio de 2018

Derecho de autor
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.
Asher Kleiman Reynaldo Quintero

C.I.: 24812812 C.I.: 25211857
En la ciudad de Caracas, a los treinta y un (31) días del mes de mayo del año 2018
ii
Aprobación
Considero que el Trabajo Final titulado
GraphQL vs REST: una comparación de rendimiento a nivel práctico.
Elaborado por los ciudadanos
Asher Kleiman
Reynaldo Quintero
Para optar al título de
INGENIERO DE SISTEMAS
Reúne los requisitos exigidos por la Escuela de Ingeniería de Sistemas de la

Universidad Metropolitana, y tiene méritos suficientes como para ser sometido a la
presentación y evaluación exhaustiva por parte del jurado examinador que se designe.
En la ciudad de Caracas, a los veintinueve (15) días del mes de junio del año 2018.
Christian Guillén Drija Tutor _______________________
iii
Acta de veredicto
REEMPLAZAR ESTA PAGINA POR EL ACTA DE VEREDICTO REAL
iv
Agradecimientos
La finalización de nuestro trabajo de grado tiene muchos actores que, de alguna

manera u otra, nos ayudaron para llevar a cabo este tomo. Nada de lo que está aquí
escrito hubiese sido posible sin todas aquellas personas que creyeron en nosotros y
siempre estuvieron ahí para dar palabras de aliento cuando fuese necesario.
Principalmente quiero agradecer a mi familia, quienes siempre han estado
presentes en los momentos importantes, tanto buenos como malos. Mis padres,
Jacobo y Judith, que siempre, sin importar la situación, me han apoyado en todo lo que
emprendo y me han aconsejado de la mejor manera para ayudarme a alcanzar mis
metas. Mis hermanas, Fanny y Grace, quienes siempre me brindan su amor
incondicional y que han sido segundas madres a lo largo de toda mi vida. Y también, no
puede faltar agradecer a todo el resto de mi familia que siempre ha estado pendiente
de mí y sé que, a pesar de la distancia, siempre puedo contar con cada uno de ellos
para cada momento.
También quiero agradecer a mis compañeros, que recorrieron conmigo todo este
trayecto universitario, siempre trabajando juntos para alcanzar una meta común y
apoyándonos los unos a los otros en buenas y malas. A Reynaldo, quien es el mejor
compañero que podría haber pedido tanto para este trabajo como para todo nuestro
camino universitario y quien, después de luchar juntos por tanto tiempo, se convirtió en
un hermano para mí. A Andrea, quien se mantuvo a mi lado por los cuatro años que
estuvimos estudiando juntos en la universidad, que me cuido en los malos momentos y
celebro los buenos; jamás he conocido una persona más especial y talentosa. A Jose
Luis, que fue la persona que originalmente nos dio el tema de este trabajo y nos orientó
en más de una ocasión en distintos aspectos de nuestra carrera, un modelo a seguir
con su gran animo al abarcar cualquier proyecto que se propone. A Rafael y Victoria,
quienes presentaron su tesis a la par con nosotros y cumplieron con esta meta de la
misma manera, son personas admirables que se esfuerzan al máximo a cada
momento. Y también le agradezco a incontables personas que influenciaron mi trayecto
por la universidad y me moldearon a ser el ingeniero que soy hoy.
Por otro lado, también le agradezco a todo el equipo de Aether Solutions,
principalmente a Andres, Alejandro y Bernardo quienes desde la experiencia nos han
guiado y ayudado con todo lo que han podido. Para todos, gracias por los buenos
ratos, las risas y todo el apoyo que nos brindaron, no existe en el mundo un mejor
equipo.
Y finalmente a Christian, quien fue un tutor ejemplar y que siempre se mostró
interesado con cada aspecto del trabajo, nunca dejando de lado su aprecio y apoyo.
Asher Kleiman
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
Figura 1. Comunicación a través de Hyper Text Transfer Protocol utilizando la arquitectura

cliente-servidor........................................................................................................................... 8
Figura 2. Esquema ejemplo de GraphQL. .................................................................................18
Figura 3. Ejemplo de un Query. ................................................................................................20
Figura 4. Ejemplo de una Mutation............................................................................................21
Figura 5. Extracto de Código de frontend donde se resaltan las líneas donde se utilizan la
función sizeof() para determinar el tamaño de una variable u objeto.........................................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. ....................................................................................34
Figura 7. Extracto de código utilizado para la prueba de rendimiento. ......................................35
Figura 8. Extracto de código de las API's implementadas en la que se detallan los modelos de
las entidades o recursos utilizados............................................................................................38
Figura 9. Extracto de Código de la API que representó al estilo REST, sección de endpoints,
primera parte. ...........................................................................................................................43
segunda parte. ..........................................................................................................................44
tercera parte. ............................................................................................................................45
Figura 12. Extracto de Código de la API que representó al estilo REST, función de caché. ......46
Figura 13. Extracto de Código de la API que representó al estilo REST, ejemplo de
implementación de caché. ........................................................................................................47
Figura 14. Modelos pertenecientes al software desarrollado bajo la arquitectura REST. ..........48
Figura 15. Respuesta recibida de un query realizado a la API representante de REST. ...........49
Figura 16. Esquema realizado en GraphQL, Queries y Mutations. ............................................50
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. ..........................52
Figura 19. Resolvers para los campos complejos de los types. ................................................53
Figura 20. Resolvers para los queries. ......................................................................................53
Figura 21. Resolvers para las mutations. ..................................................................................54
Figura 22. Captura de pantalla de interfaz de evaluación desarrollada. ....................................55
Figura 23. Ejemplo de función para hacer una petición y medir respuesta, caso GraphQL. ......56
Figura 24. Ejemplo de función para hacer una petición y medir respuesta, caso REST. ...........56
xii
Resumen
GraphQL vs REST: una comparación de rendimiento a nivel práctico.
Autores: Asher Kleiman

Reynaldo Quintero
Caracas, junio 2018
Tutor: Christian Guillen
El presente trabajo de investigación se centró en el estudio de dos opciones

disponibles para la comunicación cliente-servidor, específicamente el frontend y el
backend de una plataforma web, para determinar cuál es la más conveniente con base
en su eficiencia. Estas dos opciones, GraphQL y REST, fueron evaluadas en el marco
de las métricas de ISO 9126 e ISO 25010, específicamente en el ámbito de su eficiencia
de desempeño, siendo esto último el objetivo de la presente investigación. De esta forma,
se intentó responder a la necesidad de determinar cuál de estos mecanismos tiene un
mayor grado de eficiencia, interrogante que se pueden plantear futuros desarrolladores
cuando se vean obligados a tomar decisiones arquitectónicas en el contexto de un
conjunto de requerimientos iniciales. La investigación bibliográfica que se realizó tuvo el
propósito de definir los requerimientos para el posterior desarrollo de las API’s necesarias
para realizar la experimentación. En el diseño experimental se colocó especial cuidado
en la selección del conjunto de herramientas, con el fin de asegurar en lo posible, la
ejecución de las mediciones necesarias, que con base en las métricas escogidas,
soportaran el logro de los objetivos planteados. Finalmente, se obtuvo un conjunto de
resultados que, junto con la interpretación provista, pueden ayudar en la toma de
decisiones durante el diseño arquitectónico de un sistema, lo que se constituye como el
principal aporte de este trabajo.
Palabras clave: Comunicación Cliente-Servidor, API, Mecanismo

Arquitectónico, Desarrollo, Eficiencia, ISO 9126 e ISO 25010, Comparación.
xiii
Introducción
La evolución constante de la web, desde el nacimiento formal de la World Wide Web

en 1990, ha estado acompañada del ingenio humano con el objetivo de lograr
arquitecturas que apoyen un uso más extenso y más profundo de las utilidades y
funcionalidades que todo el sistema mundial de información pone a disposición. Bajo
este mismo propósito de crear un mundo donde la información es cada vez más
accesible, las API’s fueron desarrolladas como un concepto arquitectónico de software
para crear puertas a dicha informació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.
En este trabajo de investigación se exploraron y evaluaron, lado a lado, dos

implementaciones muy distintas de API’s: REST y GraphQL. Estas dos, aunque muy
alejadas en su naturaleza, debido a que la primera se define como un estilo
arquitectónico y la segunda como una tecnología, pueden llevarse a un nivel en el cual
sean comparables de forma que se puedan discernir las ventajas y desventajas de una
con respecto a la otra. En este sentido, este escrito exploró a REST y a GraphQL como
mecanismos arquitectónicos, y fueron evaluadas a un nivel práctico para proporcionar
un nivel concreto de información que apoye el juicio del diseñador o arquitecto de
software.
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.
Con base en lo anteriormente expresado, se pretendió entonces llevar a cabo una

experiencia investigativa en la que se aplicasen métricas preestablecidas para evaluar
ambas opciones. Dichas métricas fueron construidas con base en los estándares ISO,
específicamente ISO 9126 e ISO 25010 y a partir de estas se creó un marco comparativo
que pudiese coadyuvar a un mejor discernimiento en cuanto a la comparación de las
capacidades de ambas y sus utilidades.
Todo lo anterior es con el objeto de ayudar a los desarrolladores, y cualquier otro

involucrado en el proceso de desarrollo de software, a generar decisiones de calidad y
cada vez más acertadas en cuanto a sus opciones de arquitectura, y así utilizar las
herramientas correctas para el negocio, producto o servicio, que se estén planteando.
2
Capítulo I. Tema de Investigación
I.1Planteamiento del Problema
Desde antes de que existiese la World Wide Web, la utilización de varios

computadores para la ejecución de una tarea se había discutido extensivamente.
Terminando la década de los 1960, Rulifson (1969), en el documento RFC 5, planteaba
un lenguaje de programación de redes computacionales que permitiese que una
computadora recibiese la entrada de datos a través de una interfaz gráfica y esta misma
transmitiese los datos ingresados a otra que utilizase los datos para generar la
información que realmente buscaba el usuario.
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.
Se presenta entonces la disyuntiva en la elección de la tecnología al momento de

programar una API. Por un lado, se encuentra el estilo REST, con más de 15 años de
existencia y con la infraestructura que se ha creado alrededor de él en ese tiempo; y por
el otro, se encuentra GraphQL, respaldado por una compañía de éxito global, con
creciente popularidad en el mundo de los desarrolladores y con un nuevo acercamiento
a la comunicación de las API's.
De tal forma se plantea la siguiente interrogante, ¿Cuál de las dos tecnologías
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.2.1 Objetivo General
Evaluar los mecanismos arquitectónicos REST y GraphQL en el contexto de la

comunicación de una API con un sitio web.
I.2.2 Objetivos Específicos
● Diseñar el marco de comparación de los mecanismos seleccionados, basado en

los estándares internacionales ISO 9126 e ISO 25010, específicamente en el ámbito de
eficiencia de desempeño, a partir de los parámetros específicos identificados en la
revisión bibliográfica.
● Diseñar un caso de estudio que permita comparar los mecanismos escogidos.
● Desarrollar las API's correspondientes para implementar REST y GraphQL

respectivamente, junto con el sitio web que hará uso de las mismas.
● Caracterizar las ventajas y desventajas de las dos API's desarrolladas.
I.3 Limitaciones
Para el desarrollo de esta investigación fue necesario el diseño e implementación de

software que permitiera realizar la parte experimental. Para ello se utilizaron tecnologías
de amplio uso y documentación: NodeJS, Express y Angular 5. Con estas tecnologías se
desarrollaron dos API’s, una con una arquitectura RESTful, fiel a los requerimientos
dados por Roy Fielding en su tesis doctoral, y otra con una implementación de la
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.
Toda la información obtenida de la experimentación se derivó de la aplicación del

conjunto de software desarrollado por los investigadores con base en las herramientas
escogidas. Por tal razón, la interpretación de tales datos se complementa con las
referencias a las descripciones de las limitaciones que estos programas, desarrollados o
adaptados, heredaron de estas, según la visión de los autores.
6
Capítulo II. Marco Teórico
En el capítulo anterior se ha expuesto un panorama general acerca de la situación

actual del área de programación de API’s y su forma de comunicación con los sitios web.
En este capítulo se profundizará cada área del conocimiento que se considera de vital
importancia para la comprensión integral de la investigación realizada.
II.1 Tecnología y paradigmas del área
II.1.1 Application Programming Interface
Una Application Programming Interface, es un término que se utiliza en diferentes

contextos dentro del mundo de la ingeniería de software. En general, se refiere a la
interfaz de un elemento de software que puede ser llamado o ejecutado. (Eizinger, 2017).
En el presente trabajo de investigación, especificaremos a una API como un software
capaz de ser accedido a través de peticiones que utilicen el Hyper Text Transfer Protocol
o HTTP por un sitio web, que permite generar data y proveer funcionalidades a través de
interfaces definidas, sin ofrecer en ningún momento una interfaz gráfica al usuario.
II.1.2 Arquitectura Cliente-Servidor
La arquitectura cliente servidor es la forma más común de arquitectura de redes

utilizada hoy en día. Es un estándar que se ocupa de la separación de los trabajos que
se necesitan para cumplir con una cierta tarea específica. Esta separación se da en la
forma de un cliente y un servidor, como bien lo sugiere el nombre de la arquitectura.
Un cliente puede ser definido como un sistema o programa que se encarga de
recoger los datos y las peticiones de los usuarios, para luego traducirlas en el formato
adecuado y hacerlas llegar a un servidor.
Un servidor puede ser definido como un sistema o programa que recibe diferentes
peticiones de varios clientes y que se encarga de generar la respuesta adecuada para
cada petición específica, enviándola en un formato determinado al cliente
correspondiente.
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.
Figura 1. Comunicación a través de Hyper Text Transfer Protocol utilizando la

arquitectura cliente-servidor.
Fuente: Held, G., 2000, p. 11
II.1.3 Hyper Text Transfer Protocol
Un aspecto en el que, a la luz del tema de investigación del presente trabajo, es

necesario tratar, es el significado del término de Hypertext Transfer Protocol, de ahora
en adelante HTTP, debido a que es uno de los protocolos más ampliamente adoptados
en el internet para la comunicación de la arquitectura cliente-servidor (Grigorik, 2013).
Este protocolo surge a principio de la década de los 1990, con un conjunto de
publicaciones de la serie de Request for Comments, RFC de ahora en adelante, que son
producto de la organización reconocida mundialmente Internet Engineering Task Force,
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.
II.1.4 Estilo arquitectónico y la tecnología.
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.
II.1.5 Underfetching y overfetching
Los conceptos de underfetching y overfetching vienen de problemas muy comunes

que tienen las API’s orientadas a recursos, tal como lo es REST. Un resumen de esto
según la iniciativa open-source How To GraphQL (2018) se presenta a continuación.
El primero de estos, underfetching, quiere decir que la cantidad de data que se
encuentra en un endpoint1 determinado no es suficiente para cumplir una tarea
determinada y, por lo tanto, es necesario hacer más peticiones para obtener toda la
información que se requiere. Se puede ver cómo esto puede ser un problema debido a
que una mayor cantidad de peticiones implican más recursos de cliente y de servidor que
deben disponerse para tal tarea, cuando una sola petición pudiese ser suficiente.
Luego, overfetching, es otro concepto que cubre la parte contraria a underfetching.
De tal forma, este indica que la cantidad de información que se encuentra en el URI de
un recurso determinado es mayor que la que se determina como útil para su función. Es
decir, la cantidad de información que recibe el cliente de parte de la API de un recurso y
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.
II.2 Comunicación con API's
En la sección anterior, se describió la forma en la que se lleva a cabo la comunicación

con las API's. Se estableció que la comunicación se llevaba a cabo utilizando HTTP como
protocolo y utilizando el estilo arquitectónico de cliente-servidor.
Como bien se estableció en el capítulo I, en la sección de planteamiento del
problema; durante mucho tiempo se utilizó el Representational State Transfer como el
mecanismo arquitectónico de preferencia para llevar a cabo la comunicación de una API
y un sitio web a través de HTTP. También se expresó que en el año 2015 había entrado
en la competencia GraphQL como contraparte al Representational State Transfer. Se
busca entonces en esta sección definir ambos mecanismos.
II.2.1 Representational State Transfer
El Representational State Transfer, de ahora en adelante referido como REST, es

un estilo arquitectónico introducido en el año 2000 por Roy Fielding en su tesis doctoral.
Este estilo es introducido para poder definir la arquitectura que debía tener en el
momento el World Wide Web (Massé, 2011).
De hecho, puede definirse REST como un estilo arquitectónico diseñado para la
World Wide Web basado en los conceptos de HTTP, URI y Hypertext Markup Language,
de ahora en adelante referido como HTML, que son considerados vitales para la red de
la que se está hablando.
Sin embargo, el conjunto de restricciones que se establecieron por el estilo REST,
son aplicables para las API’s. Esto es debido a que las API’s pueden considerarse como
partes esenciales de la World Wide Web, debido a su constante comunicación con los
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.
II.2.1.2 Sin Estado

Una vez establecida la arquitectura cliente-servidor, se observa ahora esta
restricción que afecta directamente a esta arquitectura: la comunicación entre los clientes
y el servidor debe mantenerse siempre sin que el servidor deba guardar el estado del
cliente.
Debido a esta restricción, cada petición que el lado de cliente realice, debe poseer
toda la información necesaria para que el servidor pueda responder correctamente. El
servidor, por lo tanto, jamás poseerá de antemano ningún tipo de información que
describa el estado del cliente que realiza la petición. Esta restricción permite al servidor
enfocarse únicamente en las funciones que se le asignaron para crear una respuesta
veloz a los diferentes clientes que la soliciten y, de esta forma, poder atender a una mayor
cantidad de los mismos (Fielding, 2000 y Massé, 2011).
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).
II.2.1.4 Interfaz uniforme

Esta restricción está dirigida a las interfaces mediantes las cuales los componentes
del sistema se comunican, que serían: el cliente, el servidor y cualquier intermediario
entre ellos, como lo es el cache.
Se refiere a que se aplica una generalización a las diferentes interfaces de cada
componente, de forma que las interfaces se desligan de los servicios que se ofrecen,
generando así una simplificación de la comunicación y permitiendo de esta forma una
evolución independiente de cada componente, puesto que las interfaces estandarizan la
comunicación entre ellos. Sin embargo, esta estandarización trae como consecuencia
una baja de la eficiencia, puesto que la información se transmite de forma generalizada
independientemente de las necesidades del componente (Fielding, R., 2000).
Para poder garantizar que esta restricción se cumple, surgen 4 sub-restricciones
asociadas:
II.2.1.4.1 Identificación de los recursos

Cada uno de los recursos que existan en el servidor debe estar representado por un
único URI. Los conceptos de recurso y URI fueron ya explicados en la sección II.1.3.
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).
II.2.1.4.3 Mensajes auto-descriptivos

Cada uno de los mensajes que son enviados entre los componentes (al ser una
comunicación con estados, donde se expresa su cachabilidad, donde la representación
incluso posee metadata que indica la manera de interpretar la data que acompaña, donde
se utiliza el protocolo HTTP y sus encabezados correspondientes) son completamente
auto-descriptivos (Fielding, 2000 y Massé, 2011).
Esto quiere decir que, cualquier sistema que planee utilizar REST como estilo
arquitectónico, debe asegurar que cada uno de los mensajes que se manden sea
autodescriptivo, lo que significa que ninguno de los componentes debería poseer
información preconcebida acerca de los demás componentes con los que interactúa.
II.2.1.4.4 Hypermedia como el motor del estado de la aplicación

Esta restricción se refiere a que la representación de un recurso específico debe
referenciar a otros recursos relacionados a él mediante la mención de sus URI
respectivos. De esta forma, no se necesita información previa acerca de la estructura del
servidor y de la forma de acceso de diferentes recursos relacionados con uno que fue
recibido anteriormente, puesto que debe ser la hypermedia la que impulse la
representación del estado de un recurso. Si se cumple esta restricción, se garantiza que
verdaderamente se está representando el estado completo de un recurso, puesto que el
mismo permite describir sus relaciones y, por lo tanto, su contexto (Fielding, 2008).
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.1.6 Código por demanda

Esta última restricción es la única que fue considerada como opcional. Consiste en
permitir una interacción especial entre el cliente y el servidor en la que el último
proporciona al primero algún código externo o plug-in que lo habilita para realizar
acciones nuevas. Ejemplo de esta interacción es el uso de flash para crear páginas web,
puesto que el cliente, sin recibir instrucciones del plug-in que reconoce el código flash,
no puede ejecutar dicho código. De esta forma, se reduce en gran cantidad los pre-
requisitos que necesita el cliente para funcionar correctamente y satisfacer las
necesidades del usuario (Fielding, 2000 y Massé, 2011).
Esta restricción es opcional, debido a que no ocurre con garantía que el cliente
necesite recibir instrucciones del servidor para poder ejecutar código que se posee.
II.2.2 GraphQL
GraphQL es una tecnología desarrollada por la compañía Facebook inicialmente en

el año 2012 de forma interna y que deciden luego publicar para su uso gratuito en el
mundo entero en el año 2015. Esta iniciativa se desarrolla debido a la necesidad
identificada por la compañía de rediseñar el modelo de búsqueda de datos a una API
que no tomara gran esfuerzo de parte del servidor para preparar la data y de parte del
cliente para transformarla y adecuarla a un uso (Byron, 2015).
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
Una de las principales características de GraphQL es que utiliza un esquema base

que representará toda la data que se encuentra en la API. Es incorrecto, entonces,
referirse a estos tipos de data como recursos, pues no responden a un URI específico.
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.
En el esquema, se definen diferentes Types, definiendo la forma en la que estos se

relacionan y cómo están compuestos. Como ejemplo, puede verse que existe el tipo User
con su conjunto de campos o atributos; inmediatamente después puede observarse el
tipo Post, que posee como uno de sus campos un author, que a su vez es de tipo User,
indicando que existe una relación entre estos dos tipos: un User será un author para un
Post específico.
Figura 2. Esquema ejemplo de GraphQL.

Fuente: Eizinger, T., 2017, p. 8
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
Un query (o petición en español) es el mensaje que se le envía al servidor para lograr

extraer información de un servicio GraphQL. En la figura 3 se puede apreciar un ejemplo,
con base en el esquema especificado en la figura 2, de una petición. Como se puede
observar el query hace un tipo de petición específica que es timeline, lo cual está pidiendo
posts en relación a un usuario que es pasado por parámetros como of.
Además, se puede apreciar la utilización de un fragment (fragmento en español) que

permite la reutilización de peticiones de atributos específicos bajo un nombre dado,
basicPostFields en este caso. También se observa en la figura 3, la utilización del atributo
de Post, replies, lo que indica al servicio GraphQL que también se están requiriendo
todas las respuestas de todos los Posts que se encuentren del usuario. Cuando se hace
un query, GraphQL requiere que todos los atributos requeridos sean tipos primitivos para
aumentar la predictibilidad.
19
Figura 3. Ejemplo de un Query.
II.2.2.4 Mutations
Una Mutation (o mutación en español) es un query que se le permite tener un efecto

secundario, por lo que se utilizan para cambiar data en el servidor (Eizinger, T., 2017).
Estos efectos pueden ser cualquiera de los permitidos sobre una base de datos, es decir,
creación, edición y eliminación de datos. Las mutaciones también retornan una respuesta
del servidor, por lo que se podría realizar un query dependiendo de ello.
En la figura 4 se muestra un ejemplo que ilustra la formulación de una mutación. La
petición está utilizando la mutación writePost que toma los parámetros authorNick y
content para realizar la operación que esté relacionada, la cual es guardar bajo un autor
específico un post nuevo.
Además, se puede observar que se envían ciertos campos, seguidos de la
formulación de la función con sus parámetros. Estos campos representan la información
que será retornada cuando la mutación sea realizada en la capa de datos de la
aplicación, en relación a la operación.
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.
II.3 Herramientas del Método Evaluativo
Las Herramientas de Método Evaluativo se refieren a todos aquellos estándares y

métricas que se utilizarán para lograr realizar la evaluación pertinente con apoyo de estos,
de forma que la investigación está respaldada por estándares internacionales.
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.
II.3.2.1 Eficiencia (ISO 9126-3)
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)
Con respecto al ISO/IEC 25010, el área de eficiencia de desempeño “...

representa el desempeño relativo a la cantidad de recursos utilizados bajo determinadas
condiciones.” (ISO, 2011). Esta área se subdivide en las siguientes características (ISO,
2011):
o Comportamiento temporal: Los tiempos de respuesta y procesamiento y los
ratios de throughput2 de un sistema cuando lleva a cabo sus funciones bajo
condiciones determinadas en relación con un banco de pruebas o
benchmark establecido.
o Utilización de recursos: Las cantidades y tipos de recursos utilizados
cuando el software lleva a cabo su función bajo condiciones determinadas.
o Capacidad: Grado en que los límites máximos de un parámetro de un
producto o sistema software cumplen con los requisitos.
II.4 Tecnologías a utilizar
Las herramientas que se describen a continuación fueron las que el equipo de

investigadores seleccionó para poder llevar a cabo la experimentación. Estos software
apoyaron la creación del ambiente que rodeó a los mecanismos arquitectónicos
evaluados y así brindar las condiciones para una experimentación veraz.
II.4.1 Node.js
En el sitio oficial de Node.js (2018), describen esta pieza de software como un

entorno de ejecución para JavaScript construido con el motor de JavaScript V8 de
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
Según la documentación oficial de Angular 5 (Google, 2018), este es un

framework para construir aplicaciones cliente en HTML en JavaScript o TypeScript, que
es un lenguaje que complementa JavaScript.
Este framework abasteció las herramientas necesarias para la construcción de
una interfaz que permita interactuar con las aplicaciones web desarrolladas con Express,
anteriormente mencionada; y de tal manera evaluar los puntos establecidos.
II.4.4 Herramientas para la Evaluación
Las herramientas que se utilizaron para la ejecución de las pruebas y la medición de

los parámetros establecidos fueron escogidas de los módulos de Node que están
disponibles en el ecosistema de paquetes de npm. No obstante, algunas de las
herramientas fueron desarrolladas en conjunto del ambiente de evaluación para facilitar
la integración de los métodos evaluativos dentro de los procesos del sistema.
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
Sizeof (2014) es un paquete que se encuentra en el ambiente de paquetes de Node

con npm. Este se utiliza para medir el tamaño de variables y objetos pertinentes. Este se
utiliza declarando una instancia de la clase Sizeof, la cual contiene las funciones que se
utilizarían para el propósito ya mencionado. En confirmación de lo anterior, en el sitio
oficial de npm, la sección que describe el paquete Sizeof expone que la función de la
librería es calcular el peso aproximado de un objeto de Javascript.
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
III.1 Tipo de estudio
Según Hernández, Fernández y Baptista (2014), una investigación explicativa busca

darle explicación a un fenómeno estudiado, respondiendo por las causas de los eventos.
Esta descripción aplica perfectamente a la investigación realizada, puesto que en la
misma se buscó, mediante un conjunto de variables planteadas posteriormente en el
escrito, determinar el mecanismo arquitectónico que era considerado más efectivo
únicamente a nivel de rendimiento, explicando las razones por las que esto ocurre.
El enfoque que se decidió dar a la investigación fue el cuantitativo, debido a que la
misma busca únicamente medir magnitudes que, una vez tomadas, permitieran
responder a la interrogante planteada, que era conocer cuál de los dos mecanismos
arquitectónicos era considerado el mejor desde un punto de vista de rendimiento,
aplicando perfectamente a la definición de Hernández, Fernández y Baptista (2014) para
este tipo de enfoque y a su secuencia rigurosa de acción: plantear el problema, investigar
la bibliografía, acotar la investigación, definir variables e hipótesis, diseñar la
investigación, definir la muestra, recolectar los datos, analizarlos y reportarlos.
III.2 Variables y Operacionalización
Las variables que se estudiaron en el presente trabajo investigativo fueron

únicamente aquellas que permitieran medir el rendimiento de los mecanismos
arquitectónicos implementados en las API's generadas. Para ello, se decidió hacer uso
de los estándares internacionales ISO 9126 e ISO 25010, ya explicados en el marco
referencial.
Ambos estándares por poco tratan las mismas áreas, con diferencia en la última, en
la que ISO 9126 toma como característica el total de metas de rendimiento cumplidas en
comparación con las definidas por un organismo externo o por la misma persona, natural
o jurídica, que crea el software; en cambio, en la más nueva versión 25010, esta
característica fue eliminada y ahora se toma en cuenta la capacidad del software, que
contempla la máxima capacidad del mismo con respecto a diferentes aspectos como lo
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.
Categoría Nombre Propósito Método de Fórmula Interpretación Tipo de Origen de

de la de la aplicación medida la medida
métrica métrica
Tiempo de Determinar Evaluar la X = tiempo Mientras más X = ms Tiempo

respuesta el tiempo velocidad de (calculado) bajo el valor esperado de la
que toma respuesta a las obtenido, mejor. realización de
realizar una llamadas al una llamada
llamada backend para atómica al
atómica en operaciones backend
la API atómicas.
Se medirá el
tiempo
completo
desde que se
realiza la
llamada a la
API hasta que
Comportamiento temporal
llega la
respuesta
deseada.
Rendimiento Determinar Evaluar la X= Mientras más X= Cantidad de

o throughput la cantidad eficiencia de cantidad de alta la tasa llamadas llamadas
de las llamadas al llamadas / obtenida, mejor. completas / realizadas al
operaciones backend para unidad de ms backend
que pueden operaciones tiempo respondidas
completarse atómicas. exitósamente
en una Se medirán la
unidad de cantidad de
tiempo llamadas
respondidas
exitósamente
que pueden
llevarse a cabo
en una unidad
de tiempo a
través de la
API.
Fuente: Elaboración propia
29
Tabla 2: Sección de utilización de recursos del marco comparativo utilizado en las
API's desarrolladas.
Categoría Nombre de Propósito de Método de Fórmula Interpretación Tipo Origen de la

la métrica la métrica aplicación de medida
medida
Utilización Determinar el Estimar el X = tamaño Mientras menor X= Tamaño de la

de la tamaño de requerimient en bytes sea el valor, bytes respuesta de
memoria memoria que o de (calculado) mejor. una operación
se utiliza para memoria atómica
recibir una
respuesta a
una operación
atómica
Utilización Determinar Estimar la X= Mientras mayor X = tasa Cantidad de

de caché cuántas veces utilidad que llamadas sea la tasa, operaciones
el caché es se da de que mejor que se
Utilización de recursos
utilizado para caché en la utilizaron registraron en

realizar las API caché / el sistema y
mismas desarrollada llamadas cantidad de
acciones. totales llamadas que
utilizaron el
caché según
el registro del
middleware.
Overfetching Determinar el Estimar la X= Mientras menor X= Cantidad de

porcentaje de eficiencia de cantidad de sea el valor, Bytes bytes enviados
información las bytes mejor por la API y
superflua en respuestas totales - cantidad de
promedio de recibidas a cantidad de bytes que
un conjunto través de la bytes fueron
de llamadas. API utilizados utilizados.
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.
Categoría Nombre de Propósito Método de Fórmula Interpretación Tipo de Origen

la métrica de la aplicación medida de la
métrica medida
Underfetching Determinar la Estimar la X= Mientras menor X= Cantidad de

cantidad de eficiencia de cantidad sean la cantidad llamadas llamadas
Utilización de recursos
llamadas en las de de llamadas, realizadas

promedio respuestas llamadas mejor por el
necesarias recibidas a realizadas frontend
para obtener través de la
la API
información
deseada.
Capacidad Determinar la Estimar la X= Mientras mayor la X = tasa Cantidad de

cantidad de capacidad cantidad tasa, mejor llamadas
llamadas que máxima de la de realizadas
puede API de llamadas por el
procesar la manejo de respondida frontend y
API sin fallar. tareas s con éxito cantidad de
encoladas. / cantidad respuestas
Capacidad del software
de recibidas.
llamadas
realizadas
Velocidad bajo Determinar la Estimar la X = tiempo Mientras menor la X = ms / Cantidad de

estrés velocidad de eficiencia de total de tasa, mejor llamadas llamadas
respuesta la API bajo respuesta / completas con
promedio de una situación cantidad respuesta
la API con de estrés del de en frontend
una gran sistema llamadas y el tiempo
cantidad de completad total de
tareas as espera.
encoladas.
31
III.3 Hipótesis planteada
Debido a la forma en la que trabaja GraphQL, que consiste en definir modelos de

datos a través de los ya explicados esquemas y que, por lo tanto, para cada type
generado debe verificar cómo resolver cada atributo que posee, se planteó la siguiente
hipótesis: una API creada con GraphQL poseerá un rendimiento menor que una API
basada en el estilo REST.
III.4 Instrumentos de recolección
El instrumento de recolección de data fue construido en Angular 5, cuyo motor es

NodeJS. De tal forma, se pudo implementar librerías de npm en el frontend que ayudan
a formar la herramienta, con todas las funcionalidades que esta requiere. La recolección
de la data se dividió en tres principales tipos de datos: tamaño, tiempo y peticiones.
En las figuras 5 y 6 se puede apreciar un extracto de código que representa la
medición común que se realizó al hacer una petición; sin embargo, fue necesario la
realización de una función especial para realizar, específicamente, la prueba de
rendimiento. Tal función será explicada en la sección III.4.4 de este escrito.
También, cabe destacar que las figuras 5 y 6 muestran el código tomado de las
funciones para las peticiones a GraphQL. No obstante, este no varía en el caso de REST
y es certero decir que las mediciones se realizan de la misma forma.
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.
Figura 5. Extracto de Código de frontend donde se resaltan las líneas donde se

utilizan la función sizeof() para determinar el tamaño de una variable u objeto.
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.
III.4.4 Caso especial

Debido a la forma en la que era necesario medir las respuestas en el caso de las
pruebas de rendimiento o throughput, el código es distinto al señalado en las figuras 5 y
6. Para entender a profundidad como se realizaron las peticiones para las pruebas, se
muestra, en la figura 7, el código para dicho caso especial en GraphQL. Las mediciones
en REST funcionan de la misma manera, por lo que el caso aplica para ambas
arquitecturas.
34
Figura 7. Extracto de código utilizado para la prueba de rendimiento.
Fuente: Elaboración propia.
Como se muestra en la figura 7, la función vuelve a llamarse a sí misma en el

método que maneja la respuesta de la petición http. De tal manera es posible contar
cuantas peticiones pueden ser respondidas en un tiempo de terminado. En este caso, el
tiempo de finalización es representado por la variable maxTime y se utiliza un método if
para determinar si la función ya debe terminar. Cuando entra al último ciclo, se guarda el
contador i en una fila de la tabla de data que muestra la interfaz como el campo
totalLlamadas.
III.5 Diseño de la investigación
El presente trabajo de investigación fue llevado a cabo en las siguientes fases:
III.5.1 Recolección de información

En esta fase, se llevó a cabo la consulta bibliográfica que permitió la creación de las
API’s desarrolladas, las características a ser estudiadas de las mismas, las métricas de
los estándares ISO que se utilizarían y la tecnología a ser implementada para realizar las
mediciones apropiadas de las variables.
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
Serie Aspire VN7-592G
Modelo Acer Aspire VN7-592G-71ZL
Especificaciones Técnicas
Unidad de Procesamiento Central Intel Core i7-6700HQ
Memoria RAM 8.00 GB (7.8GB Utilizables)
Unidad de Procesamiento de NVIDIA GeForce GTX 960M

Gráficos
Sistema Operativo Windows 10 Home Edition (64-bit)
III.5.3 Recolección de datos

En esta fase de la investigación, se obtuvieron los datos necesarios para poder
dar uso al marco comparativo creado, ya mostrado en las tablas 1, 2 y 3. Se dividió en
las siguientes fases:
III.5.3.1 Diseño de marco comparativo
Se creó el marco comparativo, basado en los estándares ISO 9126 e ISO 25010,
para poder estructurar las mediciones de los valores que indicarían el rendimiento de
cada una de las API’s desarrolladas. Este marco fue ya mostrado y explicado
anteriormente y corresponde a las tablas 1, 2 y 3.
III.5.3.2 Plan de pruebas
Utilizando los propósitos de cada una de las métricas definidos en las tablas 1, 2 y
3, se definieron un conjunto de consultas (queries) que serían utilizados para llevar a
cabo la medición de las distintas características que querían ser observadas.
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.
Figura 8. Extracto de código de las API's implementadas en la que se detallan los

modelos de las entidades o recursos utilizados.
Este caso de estudio se seleccionó ya que se consideró que el mismo prestaba la

suficiente generalidad para lograr representar una gran variedad de peticiones
comúnmente utilizadas, tanto para llamadas atómicas (como la búsqueda de un único
libro) como para llamadas complejas (como la llamada de un autor con todos sus libros
asociados). De esta manera y con un marco de comparación definido, se garantiza se
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.
Incluso, otra justificación para la simplicidad y generalidad del caso de estudio es

que se evita que el foco de la evaluación se moviese de los objetivos planteados debido
a la propia complejidad del sistema. Un sistema más sencillo permite que las pruebas
realmente se limiten a evaluar la eficiencia de la API y no del backend al que sirve de
interfaz.
III.5.3.4 Diseño del frontend y las herramientas de medición

En esta fase, se llevó a cabo el análisis de los requisitos necesarios que debía
cumplir la interfaz y el frontend como un todo para poder llevar a cabo la recolección de
datos; el mismo luego fue programado para trabajar con ambas API’s, junto con el
software de medición que permitiría recolectar los datos que se colocaron posteriormente
en el marco comparativo. Dicho software de medición fue ya explicado anteriormente.
III.5.4 Análisis de datos

Ya en esta etapa, y ya habiendo ejecutado el plan de pruebas diseñado con
anterioridad para obtener los datos pertinentes que permitieran llenar el marco
comparativo, a través del software de medición y recolección desarrollado, se logró
definir una conclusión acerca de cuál de los dos mecanismos arquitectónicos, llevados a
tecnologías, tiene ventaja en el campo de rendimiento como software para el desarrollo
de API’s web, logrando así evaluar la hipótesis planteada.
39
40
Capítulo IV. Análisis de Resultados
A continuación, se presentan los resultados de la investigación junto con su análisis

pertinente, separados según los objetivos específicos planteados en el capítulo I del
presente escrito.
IV.1 Diseño del marco de comparación
Como primer objetivo del escrito, se pretendió: Diseñar el marco de comparación

de los mecanismos seleccionados, basado en los estándares internacionales ISO 9126
e ISO 25010, específicamente en el ámbito de eficiencia de desempeño, a partir de los
parámetros específicos identificados en la revisión bibliográfica. Para lograrlo, se hizo el
estudio bibliográfico pertinente de los estándares ISO/IEC 9126 y 25010 y se generó un
marco comparativo que permitiera una correcta contraposición de las diferentes
categorías que atañen únicamente al desempeño de rendimiento de las API’s
desarrolladas. Dicho marco comparativo se ve reflejado en las tablas 1, 2 y 3, reseñada
en el capítulo III del presente escrito, en la sección III.2: Variables y operacionalización.
IV.2 Diseño del caso de estudio
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
Como tercer objetivo del estudio, se planteó: Desarrollar las API’s

correspondientes para implementar REST y GraphQL respectivamente, junto con el sitio
web que hará uso de las mismas. Este objetivo implicó desarrollar una API que utilizara
al estilo arquitectónico REST de forma fiel, siguiendo cada una de sus restricciones, de
forma que pudiese representar completa y objetivamente al mismo y así poder llegar a
conclusiones reales acerca de las ventajas y desventajas de ambos mecanismos
arquitectónicos.
A continuación, se presentan cada uno de los software desarrollados:
IV.3.1 API REST

Como se mencionó anteriormente, la API desarrollada para representar al estilo
arquitectónico REST, debía cumplir con todas las restricciones planteadas por él para
ser considerada fidedigna. A continuación, se demuestra el cumplimiento de ellas.
IV.3.1.1 Arquitectura cliente-servidor

Esta restricción se cumple por defecto al estarse utilizando el estilo para
representar una interfaz entre un backend y un frontend, pues se considera al frontend
al que sirve como el cliente de dicha arquitectura y al backend como el servidor.
IV.3.1.2 Sin estado

Esta restricción establece que cualquier llamada a servidor no debe obligar al
mismo a guardar el estado del cliente que realiza la llamada. Esto quiere decir que la
petición realizada solo debe contener información para indicarle al servidor la acción que
se está pidiendo ejecutar, junto con los demás requerimientos que el servidor establezca
necesarios para poder ejecutar dicha acción, sin que el mismo deba almacenar en
ninguna área interna alguna de las características de dicho cliente.
La única área donde podría incumplirse esta restricción sería en cada uno de los
endpoints a los que el cliente tiene acceso, donde se podría guardar alguna de las
características del cliente. A continuación, se muestra el código de los endpoints creados
para uno de los modelos de información planteados en el caso de estudio: el libro. Se
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.
Figura 9. Extracto de Código de la API que representó al estilo REST, sección de

endpoints, primera parte.
43
endpoints, segunda parte.
44
endpoints, tercera parte.
Como se puede observar en las figuras 9, 10 y 11, el código se encuentra comentado

para explicar cada una de las funciones que realiza y en ninguna de ellas se menciona
el almacenamiento de alguna información del estado del cliente. Lo único que realizan
estas operaciones es la llamada a la base de datos pertinente para almacenar o para
hacer búsqueda de alguno o algunos de los ejemplares del recurso, en este caso, de los
libros.
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é.
La función hace uso del paquete memory-cache, disponible en la variable

nombrada mcache instalado en a través de npm, que permite poseer un caché en la
memoria de la computadora que haga uso del programa donde este paquete está
instalado.
Esta función fue implementada únicamente en aquellas operaciones en las que no
se afecta la data, puesto que estas modificaciones no producen el mismo resultado
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 Interfaz uniforme

Esta restricción está conformada por un conjunto de sub-restricciones que deben
cumplirse. A continuación, las mismas son comprobadas:
IV.3.1.3.1 Identificación de los recursos

Cada recurso debe estar representado por un URI único. Esto quiere decir, que,
para el caso de estudio específico seleccionado, por cada uno de los libros, autores y
géneros existentes, debe existir un URI específico y no repetible mediante el cual se
interactúa con dicho recurso. Esto también implica que cada uno de los endpoints de la
API desarrollada, realiza funciones diferentes. En las figuras 9, 10 y 11 puede observarse
que ninguno de los endpoints creados repite funcionalidad y que, aquellos que traen a
las entidades individuales o las modifican de alguna manera, lo hacen a través de un URI
específico que viene definido por el ID del mismo en la base de datos.
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.
Figura 14. Modelos pertenecientes al software desarrollado bajo la arquitectura

REST.
IV.3.1.3.3 Mensajes auto-descriptivos

Nuevamente, las figuras 8, 9 y 10 demuestran que cada uno de los resultados y un
conjunto de posibles errores vienen acompañados de un código de status y un mensaje
de error. Un ejemplo de esta respuesta puede ser observada en la figura 15, en la que
se envía incluso el formato de la respuesta.
48
Figura 15. Respuesta recibida de un query realizado a la API representante de REST.
IV.3.1.3.4 Hypermedia como motor del estado de la aplicación

Esta restricción implica que cada uno de los recursos que se envían al cliente,
debe poseer algún tipo de hypermedia que lleve a todos los demás recursos que sean
de interés y estén relacionados con él. Para esto, como puede verse en la figura 14, los
modelos se crearon para poseer cada uno de los hypertextos de sus recursos asociados.
IV.3.1.4 Sistema en capas

Al utilizarse la API en la arquitectura cliente-servidor y tener por medio de
comunicación el protocolo HTTP, esto permite que existan intermediarios entre el cliente
y la API. Ejemplos de esto pueden ser la encriptación que pueda existir en el sitio web
en forma del protocolo SSL, cualquier sistema de caché intermediario, el DNS, entre
otros.
IV.3.1.5 Código en demanda

Esta restricción fue definida ya en el capítulo II como una restricción opcional, por
lo que no será tratada.
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.
Figura 16. Esquema realizado en GraphQL, Queries y Mutations.
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.
Figura 20. Resolvers para los queries.
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.
IV.3.3 Sitio Web y herramientas de medición

Para realizar las evaluaciones diseñadas, fue necesario el desarrollo de un sitio
web que actuara como consumidor de las API’s y, a su vez, fuese capaz de medir el
rendimiento de las mismas con el objetivo de llevar a cabo las comparaciones
necesarias. En la figura 22 se puede observar la interfaz, que formó parte del desarrollo,
con la cual se puede recolectar información de ambos backends.
Figura 22. Captura de pantalla de interfaz de evaluación desarrollada.
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
A continuación se muestran los resultados de las mediciones realizadas para cada

una de las métricas expuestas en las tablas 1, 2 y 3. Cabe acotar que para cada una de
las métricas establecidas, se repitieron las pruebas 30 veces y, luego de obtener la
media, el error y la desviación estándar de los resultados, se aplicó el siguiente criterio:
si el error existente en ambas medias observadas es suficiente como para no poder
determinar cuál de las medias es mayor o menor, entonces se aumenta el número de
repeticiones de la prueba para reducir así el error (Casas, O., comunicación personal, 8
de noviembre de 2017).
IV.4.1 Tiempo de respuesta

Para llevar a cabo la medición de esta métrica, se utilizaron los siguientes queries:
● Para GraphQL, se utilizó el query:

query{
author(id: ID){
_id
given_name
middle_name
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.
En ambos casos, el parámetro ID fue tomado de forma aleatoria por el software de

medición, más una vez definido dicho ID, este fue utilizado como fijo para cada una de
las repeticiones posteriores de la medición.
El query utilizado para ambos casos es considerado atómico, pues cumple con la
definición planteada en la sección 3.2, es decir, en caso de GraphQL no se hacen
pedidos de campos complejos y en caso de REST solo se hace una operación a uno de
los endpoints; de esta manera, son considerados aptos para efectuar la medición de la
métrica de tiempo de respuesta.
Las tablas 5 y 6 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.
58
Tabla 5: Resultado de las mediciones para tiempo de respuesta, GraphQL.
Fuente: elaboración propia
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:
query{
author(id: ID){
_id
given_name
middle_name
last_name
birth_date
birth_place
death_date
death_place
age
}
}
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.
Fuente: elaboración propia.
62
Tabla 8: Resultado de las mediciones para rendimiento, REST.
Fuente: elaboración propia.
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.
IV.4.3 Utilización de la memoria

Para llevar a cabo la medición de esta métrica, se utilizaron los siguientes queries:

query{
63
book(id: ID){
_id
title
edition
year
}
}
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.
IV.4.4 Utilización de caché

En esta métrica se decidió no llevar a cabo las pruebas debido a la inexistencia
de caché en la API GraphQL. No se implementó este middleware en ella debido a que,
según el sitio oficial de GraphQL (2018), el caché es utilizado para evitar la nueva
búsqueda de un recurso que se ha identificado como encontrado anteriormente y esto
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.
Tabla 11: Resultado de las mediciones para overfetching, GraphQL.
67
Tabla 12: Resultado de las mediciones para overfetching, REST
68
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.
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.
Tabla 14: Resultado de las mediciones para underfetching, REST.
70
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.
IV.4.8 Velocidad bajo estrés

Para llevar a cabo la medición de este valor, se realizó un conjunto de queries
simultáneos a ambas API's, de forma que se generara una carga significativa para ellas,
y se evaluó la velocidad de ambas para así observar si el estrés bajo el que el sistema
se sometía afectaba en la velocidad de respuesta de cada una de las API's. Los queries
utilizados fueron del tipo atómicos, de forma que no se generara un estrés adicional a la
API realizada en GraphQL debido a la resolución de campos complejos.
una de las API's respectivamente, con su respectiva media, desviación estándar y error.
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
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
El objetivo del presente trabajo investigativo era Evaluar los mecanismos

arquitectónicos REST y GraphQL en el contexto de la comunicación de una API con un
sitio web. Con esto en mente, se puede concluir:
● Una implementación fidedigna del estilo arquitectónico REST en una API posee
una mayor rapidez de respuesta que una API creada con la tecnología GraphQL.
● Las respuestas de una API creada con la tecnología GraphQL son
considerablemente más reducidas que las respuestas que genera una API creada
siguiendo las restricciones del estilo arquitectónico REST.
● El comportamiento temporal de ambas API's bajo estrés se mantiene igual que en
llamadas únicas, es decir, la API que sigue el estilo arquitectónico REST posee mayor
velocidad de respuesta que una creada utilizando la tecnología GraphQL.
● El estilo REST impone que debe utilizarse el caché para así dar menor uso al lado
del servidor y así aumentar la velocidad de las interacciones entre el cliente y el servidor,
mientras que GraphQL como tecnología no ofrece de forma natural este middleware.
Debido a esto, una API creada siguiendo las restricciones planteadas por REST tendrá
constantemente una velocidad mayor al momento de responder peticiones comunes
frente a una API creada con la tecnología GraphQL.
● Debido a las peticiones dinámicas que pueden realizarse en GraphQL, en las que
se pueden especificar campos puntuales que se requieren y existe la posibilidad de
realizar queries anidados, GraphQL es mucho más ventajoso en las áreas de
underfetching y overfetching.
● En general, desde el punto de vista de rendimiento, GraphQL debería utilizarse
cuando se requiere menor utilización de la memoria, cuando los recursos que la API
maneja están estrechamente relacionados entre sí y cuando no se considere que vaya a
utilizarse la data completa de los recursos. REST debería utilizarse en caso de
necesitarse mayor velocidad de respuesta, cuando los recursos no están relacionados
entre sí de una forma tan estrecha y cuando se vaya a utilizar toda la data de cada uno
de los recursos manejados.
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.
Eizinger, T. (2017) API Design in Distributed Systems: A Comparison between

GraphQL and REST. [Trabajo de Maestría para optar por el título de Gran
Maestre de ciencia en ingeniería]. Universidad de ciencias aplicadas
Fachhochschule Technikum Wien, Vienna, Austria.
Fielding, R. (2000). Architectural Styles and the Design of Network-based Software

Architectures. [Trabajo de Doctorado para optar por el título de Doctor de
Filosofía en ciencias de información y computación]. Universidad de California,
Irvine, California, Estados Unidos.
Fielding, R. (2008). REST API's must be hypertext-driven. [Entrada de blog].

Universidad de California, Irvine, California, Estados Unidos. Recuperado en
http://roy.gbiv.com/untangled/2008/rest-API's-must-be-hypertext-driven. El 19 de
diciembre del 2017.
Fielding, R. et al (1999) RFC 2616: Hypertext transfer protocol -- HTTP/1.1.

Recuperado en https://tools.ietf.org/html/rfc2616#section-1.3. El 16 de noviembre
del 2017.
Google. (2018). Angular – What is Angular? [Documentación oficial de Angular]

https://angular.io/docs
GraphQl (2018) Caching. [Documentación de la tecnología en línea] Recuperado de:

https://graphql.org/learn/caching/
Grigorik, I. (2013) High Performance Browser Networking: What Every Web Developer
Should Know About Networking and Browser Performance. Sebastopol,
California, Estados Unidos: O’Reilly.
Gutiérrez, D. (2011) Arquitectura de Software (Estilos Arquitectónicos). [Presentación

en línea] Recuperado en
http://www.codecompiling.net/files/slides/IS_clase_08_estilos_arquitectonicos.pd
f. El 16 de noviembre del 2017.
77
Held, G. (2000). Server management. Boca Raton, Florida, Estados Unidos: Auerbach.
Hernández, R., Fernández, C., Baptista, P. (2014) Metodología de la Investigación (6ta

edición). Mexico: McGraw Hill Education.
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]
IEC (2018) About The IEC. [En línea] http://www.iec.ch/about/
ISO (2018) About ISO. [En línea] https://www.iso.org/about-us.html
ISO (2011) ISO/IEC 25010. [En línea] http://iso25000.com/index.php/normas-iso-

25000/iso-25010
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.
Nadareishvili, I. (2013). Web of API's with Hypermedia and Node.js. [Transcripción de

una charla]. Recuperado en http://www.freshblurbs.com/blog/2013/12/03/web-
hypermedia-API's-node.html. El 16 de noviembre del 2017.
Node.js Foundation. (2018). Docs | Node.js. [Documentación oficial de Node.js].

Recuperado de: https://nodejs.org/en/docs
Node.js Foundation. (2017). Express 4.x - API Reference. [Documentación de Express

en línea]. Recuperado de: https://expressjs.com/en/api.html
Npm, Inc. (2018). npm Documentation. [Documentación oficial de npm en linea].

Recuperado de: https://docs.npmjs.com/
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/
Rulifson, J. (2 de junio de 1969) RFC 5 - Decode encode language (DEL). [Documento

en línea]. Recuperado de: https://tools.ietf.org/html/rfc5
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
View publication stats

GraphQL Vs REST

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

GraphQL Vs REST

Загружено:

Авторское право:

Доступные форматы

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

GraphQL vs REST: una comparación desde la perspectiva de eﬁciencia de

Presentation · November 2018

Christian Alfredo Guillen-Drija Reynaldo Quintero

SEE PROFILE SEE PROFILE

The user has requested enhancement of the downloaded file.

Escuela de Ingeniería de Sistemas

GraphQL vs REST: una comparación de rendimiento a nivel

Tutor: Christian Guillén

Caracas, Junio de 2018

Asher Kleiman Reynaldo Quintero

Considero que el Trabajo Final titulado

GraphQL vs REST: una comparación de rendimiento a nivel práctico.

Elaborado por los ciudadanos

Para optar al título de

Reúne los requisitos exigidos por la Escuela de Ingeniería de Sistemas de la

Christian Guillén Drija Tutor _______________________

REEMPLAZAR ESTA PAGINA POR EL ACTA DE VEREDICTO REAL

La finalización de nuestro trabajo de grado tiene muchos actores que, de alguna

Figura 1. Comunicación a través de Hyper Text Transfer Protocol utilizando la arquitectura

GraphQL vs REST: una comparación de rendimiento a nivel práctico.

Autores: Asher Kleiman

Caracas, junio 2018

Tutor: Christian Guillen

El presente trabajo de investigación se centró en el estudio de dos opciones

Palabras clave: Comunicación Cliente-Servidor, API, Mecanismo

La evolución constante de la web, desde el nacimiento formal de la World Wide Web

En este trabajo de investigación se exploraron y evaluaron, lado a lado, dos

Con base en lo anteriormente expresado, se pretendió entonces llevar a cabo una

Todo lo anterior es con el objeto de ayudar a los desarrolladores, y cualquier otro

I.1Planteamiento del Problema

Desde antes de que existiese la World Wide Web, la utilización de varios

Se presenta entonces la disyuntiva en la elección de la tecnología al momento de

De tal forma se plantea la siguiente interrogante, ¿Cuál de las dos tecnologías

I.2.1 Objetivo General

Evaluar los mecanismos arquitectónicos REST y GraphQL en el contexto de la

I.2.2 Objetivos Específicos

● Diseñar el marco de comparación de los mecanismos seleccionados, basado en

● Diseñar un caso de estudio que permita comparar los mecanismos escogidos.

● Desarrollar las API's correspondientes para implementar REST y GraphQL

● Caracterizar las ventajas y desventajas de las dos API's desarrolladas.

Para el desarrollo de esta investigación fue necesario el diseño e implementación de

Toda la información obtenida de la experimentación se derivó de la aplicación del

En el capítulo anterior se ha expuesto un panorama general acerca de la situación

II.1 Tecnología y paradigmas del área

II.1.1 Application Programming Interface

Una Application Programming Interface, es un término que se utiliza en diferentes

II.1.2 Arquitectura Cliente-Servidor

La arquitectura cliente servidor es la forma más común de arquitectura de redes

Figura 1. Comunicación a través de Hyper Text Transfer Protocol utilizando la

II.1.3 Hyper Text Transfer Protocol

Un aspecto en el que, a la luz del tema de investigación del presente trabajo, es

II.1.4 Estilo arquitectónico y la tecnología.

II.1.5 Underfetching y overfetching

Los conceptos de underfetching y overfetching vienen de problemas muy comunes

II.2 Comunicación con API's

En la sección anterior, se describió la forma en la que se lleva a cabo la comunicación

II.2.1 Representational State Transfer

El Representational State Transfer, de ahora en adelante referido como REST, es

II.2.1.2 Sin Estado

II.2.1.4 Interfaz uniforme

II.2.1.4.1 Identificación de los recursos

II.2.1.4.3 Mensajes auto-descriptivos