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).
GraphQL ofrece una alternativa eficiente y más flexible a la transferencia de estado representacional (REST) y las API RESTful, y resuelve algunas limitaciones de REST. Por ejemplo, proporcionar la capacidad de orientar los recursos con mayor precisión con una sola consulta.
GraphQL emplea una sintaxis intuitiva que permite a los clientes enviar una única consulta GraphQL a una API y recibir exactamente los datos que necesitan (en lugar de acceder a puntos finales complejos con muchos parámetros). Esta obtención de datos más eficiente puede mejorar el rendimiento del sistema y la facilidad de uso para los desarrolladores.
Esto hace que GraphQL sea especialmente útil para crear API en entornos complejos con requisitos de front-end que cambian rápidamente. Ni las API de REST ni las de GraphQL son inherentemente superiores; son herramientas diferentes que se adaptan a diferentes tareas.
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 de la API para obtener todos los datos de consulta necesarios, fuera insostenible.
Las API REST no estaban preparadas para gestionar interfaces de usuario complejas y basadas en datos, y a menudo se encontraban con problemas de latencia e ineficiencias de datos, especialmente para usuarios móviles con planes de datos limitados o caros.
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 incluye a las empresas miembro como AWS, Gatsby, Intuit y IBM en 2018.
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 con tipo dictan los tipos de datos que se pueden consultar en la API y 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. La configuración de este esquema determina en última instancia cómo se puede utilizar la API. A medida que llegan las consultas, el esquema se utiliza para la validación de solicitudes y la API de GraphQL solo ejecuta las consultas validadas.
Cada campo de un esquema está respaldado por una resolución que completa datos y determina la respuesta a un conjunto de campos. Los resolutores, 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 inicia un campo de consulta, el sistema genera una llamada al solucionador correspondiente para producir el siguiente valor. Si un campo genera un valor escalar (por ejemplo, una cadena o un número), la ejecución se completa. Si un campo genera un valor de objeto, la consulta contiene 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. Las consultas se definen en el tipo de consulta, que es un objeto especial en el código que define el punto de entrada de nivel superior para cada solicitud que los clientes pueden ejecutar contra el servidor. Cada tipo de consulta también define el nombre y el tipo de retorno para cada punto de entrada.
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. Si bien los usuarios pueden acceder a algunas consultas sin autenticación, las mutaciones siempre requieren autenticación (por ejemplo, mediante el uso de un token de API).
De manera similar a cómo funcionan las consultas, las mutaciones de GrapQL se validan contra el esquema y sus definiciones. Una vez que se valida e inicia la mutación, el servidor devuelve una respuesta JSON.
Manténgase al día sobre las tendencias más importantes e intrigantes de la industria sobre IA, automatización, datos y más con el boletín Think. Consulte la Declaración de privacidad de IBM.
Si bien las API GraphQL surgieron como una alternativa más eficiente y flexible, REST fue durante mucho tiempo el estándar para las arquitecturas API. REST es un estilo arquitectónico 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é.
Elegir entre GraphQL o REST consiste principalmente en determinar qué herramienta es mejor para el trabajo en cuestión. 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, dato o servicio accesible para el cliente) y funcionan teniendo diferentes endpoint (URL) para cada Recursos. 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 aplicar un recurso, el servidor envía un conjunto de datos completo con 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 debe realizar varias llamadas a la API debido a una recuperación de datos insuficiente de la solicitud inicial (subcaptura).
Sin embargo, GraphQL utiliza un único endpoint que proporciona una descripción completa y comprensible de los datos. Las consultas de GraphQL pueden acceder a las propiedades de los recursos y seguir referencias entre recursos. Esto permite al cliente obtener todos los datos que necesita de una única carga útil de solicitud de API y evitar problemas de sobreobtención y subobtención.
En una arquitectura RESTful, 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.
Esto significa que los desarrolladores deben crear un nuevo punto final cada vez que cambian la estructura, lo que da como resultado 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 exitosa devuelve un código de estado 200, mientras que un error de cliente podría devolver un código de estado 400 y un error de servidor podría 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 realizó 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 funciones en tiempo real con una API REST, los desarrolladores generalmente deben implementar técnicas como sondeo largo (donde el cliente sondea repetidamente el servidor en busca de nuevos datos), eventos enviados por el servidor y WebSockets, que pueden agregar complejidad a la aplicación.
Sin embargo, GraphQL incluye soporte integrado para actualizaciones en tiempo real mediante el uso de subscripciones. Las suscripciones mantienen una conexión constante con el servidor, lo que permite que el servidor envíe actualizaciones al cliente cada vez que ocurren eventos específicos y habilita a los clientes a mantenerse informados sobre los datos relevantes de la API.
El ecosistema REST está bien establecido con una amplia gama de herramientas, bibliotecas, infraestructura y tutoriales 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 y 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 diversos lenguajes de programación, incluidos JavaScript, Python, Ruby y PHP, entre otros. Las API de GraphQL han sido adoptadas por innumerables empresas, como Github, Pinterest, PayPal, Shopify, Airbnb y otras, 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 obtención de datos.1
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, los defensores de GraphQL abogan por una 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
Cree API seguras y flexibles más rápido con menos código, unificando datos para acelerar el desarrollo y la innovación.
Conecte, automatice y rompa los silos de datos para desbloquear la innovación y la velocidad con una integración segura y unificada.
Maximice el valor de la nube híbrida en la era de la IA agéntica. Acelere la transformación, modernice las aplicaciones y automatice la TI para impulsar la eficiencia, la sustentabilidad y una innovación más rápida.
1 IBM acquires GraphQL startup StepZen to step up its game in API Management, TechCrunch, 8 de febrero de 2023
2 Why GraphQL Needs an Open Federation Approach, The New Stack, 16 de noviembre de 2023