5 de noviembre de 2024
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).
GraphQL ofrece una alternativa eficiente y más flexible a la transferencia de estado representacional (REST) y a 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 utiliza una sintaxis intuitiva que permite a los clientes enviar una única consulta GraphQL a una API y recibir exactamente los datos necesarios (en lugar de acceder a endpoint 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.
Hace que GraphQL sea especialmente útil para crear API en entornos complejos con requisitos de interfaz 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 constante crecimiento y un entorno de aplicaciones móviles cada vez más complejo hicieron que su enfoque RESTful existente, que requería varios viajes de ida y vuelta a diferentes endpoint de la API para obtener todos los datos de consulta necesarios, fuera insostenible.
Las API REST estaban mal equipadas para gestionar interfaces de usuario complejas y basadas en datos, y con frecuencia tenían problemas de latencia e ineficiencias de datos, especialmente para los usuarios de dispositivos móviles con planes de datos limitados o caros.
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 GraphQL Foundation, que incluye a empresas miembro como AWS, Gatsby, Intuit e 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 datos.
Entre las que se encuentran:
- Esquemas
- Solucionadores
- Consultas
- Mutaciones
Esquemas
GraphQL se basa en un sistema de tipos sólido 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 con la que pueden interactuar los clientes de datos. 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 validar la solicitud y la API GraphQL solo ejecuta las consultas validadas.
Solucionadores
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 cloud o prácticamente cualquier otra fuente, proporcionan instrucciones para convertir una operación GraphQL (por ejemplo, una consulta, una mutación o una suscripción) en datos.
Cuando se inicia un campo de consulta, el sistema genera una llamada al resolver 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 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.
Consultas
Una consulta de datos es la solicitud realizada por el cliente al servidor de GraphQL; 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.
Mutaciones
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. Aunque 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 forma similar a cómo funcionan las consultas, las mutaciones de GraphQL se validan con el esquema y sus definiciones. Una vez validada e iniciada la mutación, el servidor devuelve una respuesta JSON.
Mantenga su cabeza en la nube
Reciba el boletín semanal Think para obtener orientación de expertos sobre cómo optimizar la configuración multinube en la era de la IA.
Aunque las API de GraphQL han surgido como una alternativa más eficiente y flexible, REST ha sido durante mucho tiempo el estándar para las arquitecturas de API. REST es un estilo arquitectónico estructurado para aplicaciones hipermedia en red, diseñado para utilizar un protocolo de comunicación sin estado, cliente/servidor y almacenable en caché (normalmente HTTP).
Elegir entre GraphQL y REST es sobre todo determinar qué herramienta es mejor para el trabajo que se va a realizar. 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 recursos (por ejemplo, cualquier tipo de objeto, dato o servicio accesible para el cliente) y funcionan teniendo 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 un conjunto de datos completo con todos los datos asociados con ese recurso. Si un cliente solo necesita un subconjunto de los datos, aun así recibe todos los datos (sobrecarga de datos); si el cliente necesita datos que abarcan varios recursos, generalmente debe realizar varias llamadas a la API debido a una recuperación insuficiente de los datos de la solicitud inicial (subcarga de datos).
GraphQL, sin embargo, 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 referencias entre recursos. Esto permite al cliente obtener todos los datos que necesita desde una única carga de solicitud de API y evitar problemas de obtención excesiva o insuficiente.
En una arquitectura RESTful, cambiar la estructura de los datos a menudo requiere que los equipos actualicen la API para evitar errores del sistema y suspensiones del servicio para el usuario.
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 complica 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 exitosa devuelve un código de estado 200, mientras que un error del cliente podría devolver un código de estado 400 y un error del servidor podría 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 la respuesta para determinar si la solicitud fue exitosa, lo que puede hacer que la depuración de las API de GraphQL sea un poco complicada.
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 el 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 suscripciones. Las suscripciones mantienen una conexión constante con el servidor, lo que permite al servidor enviar actualizaciones al cliente cada vez que ocurren eventos específicos y mantener a los clientes informados sobre los datos de la API relevantes.
El ecosistema REST está bien establecido, con una amplia gama de herramientas, bibliotecas, marcos de trabajo y tutoriales a disposición de los desarrolladores. Sin embargo, trabajar con API REST a menudo requiere que los equipos naveguen por varios endpoint y entiendan las convenciones y 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 de uso.
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 diversos lenguajes de programación, como JavaScript, Python, Ruby y PHP, entre otros. Innumerables empresas han adoptado las API de GraphQL, como Github, Pinterest, PayPal, Shopify, Airbnb y más, 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 datos1.
Además, las empresas y los desarrolladores están impulsando la federación abierta de arquitecturas GraphQL. En su iteración actual, 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 facilite la agregación de datos tanto de las API de GraphQL como de las API que no son de GraphQL en lugar de la agregación exclusiva de GraphQL2.
Recursos
Experimente IBM API Connect con una prueba sin coste o póngase en contacto con nuestros expertos para hablar de sus necesidades. Tanto si está listo para optimizar su gestión de API como si desea obtener más información, estamos aquí para guiarle en el camino hacia su transformación digital.
Descubra todo el potencial de sus procesos de integración con soluciones con IA. Concierte una reunión con nuestros expertos o explore la documentación de nuestros productos para empezar.
Potencie su negocio con las soluciones de mensajería seguras y de alto rendimiento de IBM MQ. Comience su prueba sin coste o póngase en contacto con nuestros expertos para explorar el modo en que IBM MQ puede transformar sus operaciones.
Experimente transferencias de archivos más rápidas y seguras, de cualquier tamaño y a cualquier distancia. Pruebe IBM Aspera hoy mismo y agilice sus flujos de trabajo de datos con una eficiencia y velocidad incrementadas.
Transforme su negocio al conectar aplicaciones y datos sin esfuerzo. Comience su prueba sin coste hoy mismo y descubra cómo IBM App Connect puede agilizar su proceso de integración.
Explore cómo IBM DataPower Gateway mejora la seguridad, el control y el rendimiento de sus aplicaciones locales y en la nube. Concierte una reunión ahora para empezar con una evaluación de contenedor gratuita.
Integre sus aplicaciones y automatice el trabajo con la plataforma multinube híbrida IBM webMethods.
Desbloquee el potencial empresarial con las soluciones de integración de IBM, conectando aplicaciones y sistemas para acceder a datos críticos de forma rápida y segura.
Desbloquee nuevas capacidades e impulse la agilidad empresarial con los servicios de consultoría de nube de IBM. Descubra cómo cocrear soluciones, acelerar la transformación digital y optimizar el rendimiento mediante estrategias de nube híbrida y colaboraciones con expertos.
Notas a pie de página
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