Intro a Patrones de arquitectura de APIs: GraphQL y API REST
Por: Isabel Hong y Sebastián Farías
Un problema común al que se ven enfrentados muchos equipos de desarrollo de software es la elección de la arquitectura de APIs para comunicar diferentes aplicaciones o distintas capas de una misma aplicación. Existen para abordar este problema diferentes soluciones como REST y GraphQL. Este artículo trata de esta segunda propuesta de solución.
¿Qué es GraphQL?
GraphQL es un lenguaje de consultas de APIs y un runtime o ambiente de ejecución. Fue creado por Facebook en 2012 cuando el equipo se vio enfrentado a resolver problemas en sus aplicaciones móviles. Lee Byron, el co-creador de GraphQL escribió en 2015 que a medida que las apps de Facebook se volvían más complejas, tenían problemas de rendimiento y caídas frecuentes.
Había diferencias entre la gran cantidad de datos que retornaba el servidor al hacerle una consulta, versus una menor cantidad de datos que el equipo móvil requería en el News Feed de sus apps nativas. Las opciones que tenían en ese momento eran hacer llamados a los recursos usando REST o consultar a tablas FQL — Facebook Query Language, pero ninguna de ellas solucionaba el problema.
Su solución requería otro modelo de datos que usara un grafo, donde los nodos representan a objetos y los enlaces las relaciones entre ellos.
GraphQL es un lenguaje de consulta que describe cómo un cliente debe solicitar información a través de una API. En otras palabras, GraphQL es una sintaxis para solicitar datos específicos y retornar desde múltiples fuentes.
El proyecto fue liberado públicamente en 2015 y en 2018 pasó a ser gestionado por el GraphQL Foundation y los 31 miembros incluyen a Airbnb, AWS, Apollo, Atlassian, Meta, Postman, Paypal, Microsoft, Twitter, IBM y Goldman Sachs.
¿Qué problemas soluciona GraphQL?
GraphQL resuelve limitaciones que existen en el modelo de arquitectura de API REST. Estas limitaciones están relacionadas a data fetching, envíos de solicitudes múltiples al servidor y manejo de datos — underfetching y overfetching.
Underfetching
El modelo de API REST está compuesto por múltiples endpoints donde cada uno representa un recurso. Cuando el cliente necesita datos de múltiples recursos, se necesita hacer varios llamados. Y cada llamado agrega tiempo de procesamiento y más tiempo.
El concepto de underfetching se refiere a no obtener suficientes datos al hacer una llamada a un endpoint, lo que afecta el rendimiento ya que hay que hacer llamadas adicionales a otros endpoints.
//Get a list of products
/store-api/products//Get a list of stores
/store-api/stores//Get a list of product reviews
/store-api/catalog/product/id/reviews
Overfetching
Por otro lado, hay ocasiones en que el cliente requiere solamente unos datos de un endpoint en vez de traer todos los datos. El concepto de overfetching se refiere a que la solicitud retorna más información de lo que el cliente va a usar, causando ineficiencia.
¿Qué ventaja tiene GraphQL?
Con GraphQL el cliente hace un request a través de una consulta (query) donde solicita específicamente los datos que necesita en un solo request y el servidor lo retorna en un JSON que se asemeja a la llamada.
query {
productById(id: “dflkjladerckd”){
productName
productPrice
}
storeById(id: “asfdlkjfgkjd”){
storeName
storeLocation
}
}¿Qué desventajas tiene GraphQL?
No tiene built-in server-side caching
GraphQL a diferencia de REST, no tiene soporte para almacenamiento en caché. REST está basado en diferentes endpoints y los clientes pueden usar HTTP caching y así prevenir hacer llamados múltiples al mismo recurso.
A contrario de REST, que opera con los verbos HTTP que incluyen GET, POST, PUT, DELETE; GraphQL opera con POST, ejecutando las consultas hacia un solo URL/endpoint y pasando parámetros en el body del request.
Como todos los requests se hacen hacia ese mismo endpoint, que generan diferentes respuestas dependiendo de los parámetros que se pasan, la respuesta no puede ser cacheada en el servidor usando la URL como identificador.
Las alternativas para dar soporte a cache es usar IDs únicos como identificadores globales. Otras maneras de hacer caching es hacerlo en el cliente, a través de Apollo Client, la librería de manejo de estado para Javascript y otros frameworks como Relay. Adicionalmente, una manera de escalar uniendo los diferentes servicios es usar una federación de servicios GraphQL.
Diferencias entre GraphQL y REST API
Conclusión
En la actualidad, muchas compañías siguen usando el modelo de REST API y sin necesidad de escribir el código desde cero, REST puede coexistir con GraphQL. Por ejemplo, se puede abstraer API REST con un servidor GraphQL enmascarando el endpoint de REST como un endpoint de GraphQL usando root resolvers.
Disclaimer: las declaraciones y opiniones expresadas en este artículo son las de l@s autor@s y no reflejan necesariamente las posturas de Thoughtworks.
¿Quieres formar parte de Thoughtworks? Aplica a nuestras vacantes en nuestra página web https://thght.works/3F3T4JA
