Fecha de publicación: 8 de diciembre de 2023
Colaboradores: Chrystal R. China, Michael Goodwin
GrapQL es un lenguaje de consulta de código abierto y tiempo de ejecución del lado del servidor que especifica cómo deben interactuar los clientes con las interfaces de programación de aplicaciones (API).
Con una sintaxis intuitiva que permite a los usuarios hacer solicitudes de API en una sola o varias líneas (en lugar de acceder a puntos finales complejos con muchos parámetros), las tecnologías GraphQL facilitan la generación y respuesta a las consultas de 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. Pero una base de usuarios en crecimiento y un entorno de aplicaciones móviles cada vez más complejo hicieron que su enfoque RESTful existente, que requería múltiples viajes de ida y vuelta a diferentes puntos finales para obtener todos los datos de consulta necesarios, fuera insostenible.
Las API de transferencia de estado representacional (REST) y RESTful estaban equipadas para manejar interfaces de usuario complejas y basadas en datos, además de problemas de latencia frecuentes e ineficiencias de datos, especialmente para usuarios móviles con planes de datos limitados o costosos.
En respuesta a estos problemas, los ingenieros de Facebook desarrollaron GraphQL (junto con la plataforma de aplicaciones de una sola página React) y la lanzaron como una solución de código abierto en 2015. Finalmente, Facebook trasladó el servicio a la GraphQL Foundation, que comprende empresas miembros como AWS, Gatsby, Intuit e IBM, en 2018.
Aprenda a desglosar los silos de datos escribiendo menos código con las API GraphQL de alta capacidad de respuesta.
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 los datos.
Por ejemplo:
GraphQL se basa en un sólido sistema de tipos en el que todos los tipos de datos se registran en el lenguaje de definición de esquemas (SDL) de GraphQL. Los esquemas escritos determinan los tipos de datos que pueden consultarse 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 de los datos con los que los clientes pueden interactuar.
Cada campo de un esquema está respaldado por una resolución que completa 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 de 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 GrapQL; especifica qué datos desea obtener el cliente. Cuando llega una consulta, GraphQL la valida con las definiciones del 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 de GraphQL que crean, actualizan o eliminan datos en el servidor. Son análogas de las operaciones POST, PUT, PATCH y DELETE en las API RESTful.
De manera similar a cómo funcionan las consultas, las mutaciones de GrapQL se validan contra el esquema y sus definiciones. Una vez validada y ejecutada la mutación, el servidor devuelve una respuesta JSON.
Aunque las API GraphQL han surgido como una alternativa más eficiente y flexible, REST y RESTful fueron durante mucho tiempo el estándar para las arquitecturas API. REST API es un estilo de arquitectura estructurado para aplicaciones hipermedia en red, diseñado para utilizar un protocolo de comunicación cliente-servidor (normalmente HTTP), sin estado y almacenable en caché.
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 están diseñadas en torno a los recursos (por ejemplo, cualquier tipo de objeto, datos o servicio accesible para el cliente) y funcionan con diferentes puntos finales (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 los datos, sigue recibiendo todos los datos (sobrecaptura); si el cliente necesita datos que abarquen varios recursos, a menudo tendrá que realizar varias llamadas a la API debido a una recuperación de datos inadecuada de la solicitud inicial (subcaptura).
Por otro lado, GraphQL utiliza un único punto final 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 solicitud al servidor GraphQL y evitar problemas de sobrecaptura y subcaptura.
En una arquitectura REST, cambiar la estructura de los datos a menudo requiere que los equipos versionen la API para evitar errores del sistema e interrupciones del servicio para el usuario final. Esto significa que los desarrolladores tienen que crear un nuevo punto de conexión cada vez que cambian la estructura, lo que da lugar a múltiples versiones de API y complica el proceso de mantenimiento.
GraphQL elimina la necesidad de control de versiones porque los clientes pueden especificar sus requisitos en la consulta. Si se agregan campos nuevos al servidor, los clientes que no necesitan 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 de cliente puede devolver un código de estado 400 y un error de servidor puede devolver un código de estado 500.
GraphQL maneja los errores de manera diferente. Cada solicitud, independientemente de si resultó en 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 la respuesta para determinar si la solicitud se ha realizado correctamente, lo que puede dificultar la depuración de las API GraphQL.
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 estable con el servidor, lo que permite que el servidor envíe actualizaciones al cliente cada vez que ocurren eventos específicos y permite a los clientes mantenerse al tanto de los datos de API pertinentes.
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 puntos finales y comprendan las convenciones/patrones únicos de cada API.
GrapQL es relativamente nuevo, pero el ecosistema de GrapQL ha crecido enormemente desde su introducción, con una variedad de herramientas y bibliotecas disponibles para el desarrollo de servicios de front-end 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 GraphQL. Además, GrapQL tiene un fuerte soporte para 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. Si bien son eficaces, las estrategias de almacenamiento en caché pueden ser complejas de implementar y no pueden optimizar constantemente el rendimiento para todos los casos de uso.
Las API de GrapQL 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, el almacenamiento de respuestas en caché y el almacenamiento en caché del lado del servidor pueden 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 desarrolladores han creado implementaciones para una variedad de lenguajes de programación, incluidos JavaScript, Python, Ruby y PHP, entre otros. Y las API de GrapQL 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 de datos de red excesiva o inadecuada y mejorar las capacidades generales de recuperación de datos.
Además, las empresas y los desarrolladores están impulsando una 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. Sin embargo, la implementación de la federación es exclusiva de un solo proveedor.
Como respuesta, IBM está abogando por la federación democratizada, que facilita la agregación de datos tanto de las API de GrapQL y las que no lo son, en lugar de la agregación exclusiva de GrapQL-.2
IBM API Connect es una solución para gestionar todo el ciclo de vida de las API e intuitiva que le ayuda a crear, gestionar, proteger, socializar y monetizar sus API de manera sistemática, ayudando a impulsar la transformación digital de forma local y en las distintas nubes.
IBM API Connect facilita la creación y el despliegue de una API de GraphQL a nivel de producción en minutos. Simplemente proporcione los detalles de conexión de su fuente de datos y se generará de forma instantánea una API de 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 la gestión de API 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 API para impulsar el negocio digital con una solución integral de administración de API.
IBM fue nombrada líder en el informe de Gartner 2023: capacidades críticas de API Management.
Estos tutoriales proporcionan instrucciones prácticas que ayudan a los desarrolladores a aprender a usar las tecnologías en sus proyectos.
Notas de pie de página
1"IBM adquiere StepZen, una empresa emergente de GraphQL para mejorar su apuesta 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