Publicado: 8 de diciembre de 2023
Colaboradores: Chrystal R. China, Michael Goodwin
GraphQL es un lenguaje de consulta de código abierto y un tiempo de ejecución del servidor que especifica cómo deben interactuar los clientes con las interfaces de programación de aplicaciones (API).
Al utilizar una sintaxis intuitiva que permite a los usuarios realizar solicitudes API en una sola línea o en unas pocas líneas (en lugar de acceder a endpoints complejos con muchos parámetros), las tecnologías GraphQL facilitan la generación y respuesta a consultas API. GraphQL representa una actualización de las arquitecturas RESTful tradicionales.
A principios de la década de 2010, Facebook estaba experimentando un crecimiento y una transformación masivos. Sin embargo, una base de usuarios cada vez mayor y un entorno de aplicaciones móviles cada vez más complejo hicieron que su enfoque RESTful actual, que requería varios viajes de ida y vuelta a diferentes endpoints para obtener todos los datos de consulta necesarios, fuera insostenible.
La transferencia de estado representacional (REST) y las API RESTful estaban mal equipadas para manejar interfaces de usuario complejas y basadas en datos, y con frecuencia se encontraron problemas de latencia e ineficiencias de datos, especialmente para usuarios móviles con planes de datos limitados o costosos.
En respuesta a estos desafíos, los ingenieros de Facebook desarrollaron GraphQL (junto con la plataforma de aplicaciones de una sola página React), lanzándola como una solución de código abierto en 2015. Finalmente, Facebook trasladó el servicio a la Fundación GraphQL, que comprende empresas miembros como AWS, Gatsby, Intuit e IBM, en 2018.
Aprende a desglosar los silos de datos mientras escribes menos código con API GraphQL altamente adaptables.
IBM API Connect obtiene las máximas distinciones
Las características declarativas de obtención de datos de una arquitectura GraphQL giran en torno a varios componentes y procesos clave, cada uno de los cuales desempeña un papel único en el manejo y procesamiento de datos.
Entre ellos se encuentran:
GraphQL se basa en un sistema de tipos seguro en el que todos los tipos de datos se registran en el lenguaje de definición de esquemas (SDL) de GraphQL. Los esquemas escritos dictan los tipos de datos que se pueden consultar en la API, así como las relaciones entre los tipos y las operaciones disponibles para el usuario. En otras palabras, definen las capacidades de la API y la forma con la que pueden interactuar los clientes de datos.
Cada campo de un esquema está respaldado por un solucionador que completa los datos y determina la respuesta a un conjunto de campos. Los solucionadores, que pueden recuperar datos de una base de datos, un servicio en la nube o prácticamente cualquier otra fuente, proporcionan instrucciones para convertir una operación GraphQL (por ejemplo, una consulta, mutación o suscripción) en datos.
Cuando se ejecuta un campo de consulta, el sistema genera una llamada al solucionador correspondiente para producir el siguiente valor. Si un campo produce un valor escalar (por ejemplo, una cadena o un número), la ejecución se completa. Si un campo produce un valor de objeto, la consulta contendrá más campos para ese objeto. Este proceso continúa hasta que solo quedan los campos escalares.
Los solucionadores también facilitan el formato de los datos y ayudan al sistema a unir la información de varias fuentes de datos.
Una consulta de datos es la solicitud realizada por el cliente al servidor de GraphQL; Especifica qué datos desea obtener el cliente. Cuando llega una consulta, GraphQL la valida con las definiciones de esquema y, suponiendo que la consulta sea válida, la ejecuta. La estructura de una consulta suele reflejar la estructura de los datos de respuesta, lo que hace que los requisitos de datos sean explícitos y predecibles.
Las mutaciones son operaciones GraphQL que crean, actualizan o eliminan datos en el servidor. Son análogas a las operaciones POST, PUT, PATCH y DELETE en las API RESTful.
De forma similar a cómo funcionan las consultas, las mutaciones de GraphQL se validan con el esquema y sus definiciones. Una vez validada y ejecutada la mutación, el servidor devuelve una respuesta JSON.
Si bien las API de GraphQL se han convertido en una alternativa más eficiente y flexible, REST y RESTful fueron durante mucho tiempo el estándar para las arquitecturas de API. La API REST es un estilo arquitectónico estructurado para aplicaciones hipermultimedia en red, diseñado para usar un protocolo de comunicación cliente-servidor que se puede almacenar en caché y sin estado (normalmente HTTP).
Tanto GraphQL como REST permiten a los clientes comunicarse con los servidores y solicitar datos, pero existen diferencias clave que explican la proliferación de los sistemas GraphQL.
Las API REST se diseñan en torno a los recursos (por ejemplo, cualquier tipo de objeto, dato o servicio accesible para el cliente) y funcionan con diferentes endpoints (URL) para cada recurso. Utilizan una estructura de datos fija para determinar la forma y el tamaño de los recursos que proporcionan a los clientes.
Cuando el cliente solicita un recurso, el servidor envía todos los datos asociados con ese recurso. Si un cliente solo necesita un subconjunto de datos, seguirá recibiendo todos los datos (obtención excesiva); si el cliente necesita datos que abarquen varios recursos, a menudo tendrá que realizar varias llamadas a la API debido a una recuperación inadecuada de los datos de la solicitud inicial (obtención insuficiente).
GraphQL, por otro lado, utiliza un único endpoint que proporciona una descripción completa y comprensible de los datos. Las consultas GraphQL pueden acceder a las propiedades de los recursos y seguir las referencias entre recursos, de modo que el cliente puede obtener todos los datos que necesita de una sola petición al servidor GraphQL y evitar problemas de sobrecarga y subcarga.
En una arquitectura REST, cambiar la estructura de los datos a menudo requiere que los equipos actualicen la API para evitar errores del sistema y interrupciones del servicio para el usuario final. Esto significa que los desarrolladores tienen que crear un nuevo endpoint cada vez que cambian la estructura, lo que provoca múltiples versiones de API y complican el proceso de mantenimiento.
GraphQL elimina la necesidad de crear versiones porque los clientes pueden especificar sus requisitos en la consulta. Si se agregan nuevos campos al servidor, los clientes que no necesiten esos campos no se verán afectados. Por el contrario, si los campos están obsoletos, los clientes pueden seguir solicitándolos hasta que actualicen sus consultas.
Las API REST utilizan códigos de estado HTTP para indicar el estado/éxito de una solicitud. Cada código de estado tiene un significado específico. Una solicitud correcta devuelve un código de estado 200, mientras que un error del cliente puede devolver un código de estado 400 y un error del servidor puede devolver un código de estado 500.
GraphQL maneja los errores de manera diferente. Cada solicitud, independientemente de si ha dado lugar a un error, devuelve un código de estado 200 OK. Los errores no se comunican mediante códigos de estado HTTP; en su lugar, el sistema comunica errores en el cuerpo de la respuesta junto con los datos. Este enfoque requiere que los clientes analicen el cuerpo de respuesta para determinar si la solicitud se realizó correctamente, lo que puede hacer que depurar las API de GraphQL sea un poco difícil.
REST no tiene soporte integrado para actualizaciones en tiempo real. Si una aplicación web o móvil necesita funcionalidad en tiempo real con una API REST, los desarrolladores suelen tener que implementar técnicas como long-polling (en la que el cliente sondea repetidamente al servidor en busca de nuevos datos), eventos enviados por el servidor y WebSockets, que pueden añadir complejidad a la aplicación.
Sin embargo, GraphQL incluye soporte integrado para actualizaciones en tiempo real mediante suscripciones. Las suscripciones mantienen una conexión constante con el servidor, lo que permite al servidor enviar actualizaciones al cliente cada vez que se producen eventos específicos y permitir a los clientes estar al tanto de los datos de API relevantes.
El ecosistema REST está bien establecido con una amplia gama de herramientas, bibliotecas y marcos disponibles para los desarrolladores. Sin embargo, trabajar con API REST a menudo requiere que los equipos naveguen por varios endpoints y entiendan las convenciones/patrones únicos de cada API.
GraphQL es relativamente nuevo, pero el ecosistema de GraphQL ha crecido enormemente desde su introducción, con una variedad de herramientas y bibliotecas disponibles para el desarrollo de servicios frontend y backend. Herramientas como GraphiQL, Apollo Studio y GraphQL Playground proporcionan potentes entornos de desarrollo integrados (IDE) en el navegador para explorar y probar las API de GraphQL. Además, GraphQL ofrece una gran compatibilidad con la generación de código, lo que puede simplificar el desarrollo del cliente.
Las API REST se basan en mecanismos de almacenamiento en caché HTTP, como ETags y encabezados de última modificación. Aunque eficaces, las estrategias de almacenamiento en caché pueden ser complejas de aplicar y no siempre optimizan el rendimiento en todos los casos prácticos.
Las API de GraphQL pueden ser más difíciles de almacenar en caché debido a la naturaleza dinámica de las consultas. Sin embargo, el uso de consultas persistentes, almacenamiento en caché de respuestas y almacenamiento en caché del lado del servidor puede mitigar estos desafíos y proporcionar estrategias de almacenamiento en caché eficientes para las arquitecturas de GraphQL.
Desde la transición de GraphQL a GraphQL Foundation, los programadores han creado implementaciones para una variedad de lenguajes de programación, incluidos JavaScript, Python, Ruby y PHP, entre otros. Y las API de GraphQL han sido adoptadas por innumerables empresas, como Github, Pinterest, PayPal, Shopify, Airbnb y más1, lo que permite a más clientes optimizar la especificación de datos, reducir la transmisión excesiva o inadecuada de datos de red y mejorar las capacidades generales de obtención de datos.
Además, las empresas y los desarrolladores están impulsando la federación abierta de arquitecturas GraphQL. En su iteración actual, la federación de GraphQL toma servicios de GraphQL separados y los agrega en una única API de GraphQL, que sirve como punto de entrada a todos los datos de backend subyacentes y facilita la obtención de datos de una sola solicitud. Desafortunadamente, la implementación de federación es exclusiva de un solo proveedor.
Como respuesta, IBM aboga por la federación democratizada, que facilita la agregación de datos tanto de las API GraphQL como de las API que no son GraphQL en lugar de la agregación exclusiva de GraphQL.2
IBM API Connect es una solución de gestión de API completa e intuitiva que le ayuda a crear, gestionar, proteger, socializar y monetizar sus API de manera sistemática, lo cual contribuye a una transformación digital más rápida, tanto en las instalaciones como en la nube.
IBM API Connect facilita la creación y la implementación de una API GraphQL a nivel de producción en cuestión de minutos. Simplemente proporcione los detalles de conexión de su fuente de datos y se generará al instante una API GraphQL segura y optimizada.
Conozca los dos enfoques diferentes que adoptan estos marcos para crear API y las fortalezas y debilidades de cada uno.
Lea el Cuadrante Mágico de Gartner de 2023 para API Management y descubra por qué IBM sigue siendo reconocido como líder en API Management.
Explore el kit de herramientas de IBM API Connect.
Maximice el valor de las API para impulsar el negocio digital con una solución integral de gestión de API.
IBM fue nombrada líder en el informe de Gartner de 2023: Critical Capabilities para la API Management.
Estos tutoriales proporcionan instrucciones prácticas que ayudan a los desarrolladores a aprender a utilizar las tecnologías en sus proyectos.
Notas a pie de página
1"IBM adquiere la startup GraphQL StepZen para mejorar su juego en la gestión de API" (enlace externo a ibm.com), TechCrunch, 8 de febrero de 2023
2"Por qué GraphQL necesita un enfoque de federación abierta" (enlace externo a ibm.com), The New Stack, 16 de noviembre de 2023