GraphQL es un lenguaje de consulta de código abierto para API que puede obtener datos de múltiples fuentes en una llamada a la API. También actúa como un tiempo de ejecución del lado del servidor para realizar consultas con datos existentes. GraphQL se centra en proporcionar al cliente únicamente los datos solicitados, mientras ofrece una descripción completa de los datos disponibles en la API. Este enfoque facilita tanto el escalado como la evolución de las APIs de manera eficiente.
GraphQL se diseñó pensando en la flexibilidad, la velocidad y los desarrolladores. Con GraphQL, los desarrolladores pueden crear API como mejor les parezca y, a continuación, utilizar una especificación GraphQL para garantizar que las API son funcionales para los clientes.
Uno de los principales conceptos de una consulta GraphQL es que los datos devueltos son predecibles. En lugar de recibir código innecesario, se devuelve exactamente lo que se ha solicitado. Esta obtención de datos declarativa es especialmente útil en dispositivos móviles, donde el ancho de banda es limitado. Las aplicaciones que utilizan GraphQL también son más estables y rápidas, ya que el control sobre los datos solicitados y recibidos recae en el cliente, en lugar de en el servidor. Además, son eficientes incluso en conexiones de red lentas, ya que una sola solicitud puede devolver varios elementos solicitados al mismo tiempo.
Basándose en la simplificación de datos de GraphQL, las API se organizan por tipos y campos en lugar de por puntos de conexión. Esto significa que se puede acceder a todos los datos desde un único punto de conexión, lo que permite a las aplicaciones solicitar solo lo necesario. Al reducir la complejidad operativa, GraphQL encaja en el flujo de trabajo de una solución de conectividad de API racionalizada.
En 2012, Meta (entonces Facebook) necesitaba una API de obtención de datos que fuera lo suficientemente potente para sus aplicaciones móviles de Facebook. Bajo la dirección de Lee Byron, Facebook desarrolló GraphQL como una forma de simplificar la obtención de datos, especialmente desde la perspectiva de los diseñadores y desarrolladores de productos. GraphQL fue utilizado inicialmente de manera interna en Facebook, y posteriormente se lanzó públicamente y como código abierto en 2015. Siguiendo el camino de otros proyectos de código abierto, en 2019 el proyecto GraphQL se trasladó a la Fundación GraphQL, alojada por la Fundación Linux.
GraphQL se diseñó como una alternativa a la arquitectura REST. Las API REST estándar requieren cargar información de varias URL a través de solicitudes HTTP GET independientes. Con las API GraphQL, todos los datos se recuperan a través de una única solicitud POST. Aunque tanto REST como GraphQL devuelven respuestas con formato JSON, GraphQL se centra en racionalizar y consolidar los datos.
GraphQL permite realizar solicitudes de datos detalladas y otorga a los clientes un mayor control sobre la información que se envía. El cliente envía una consulta GraphQL en forma de solicitud POST, y el servidor responde con los datos en formato JSON. GraphQL no requiere una arquitectura de aplicación específica, lo que lo hace adaptable a diversos entornos, incluidos los entornos de desarrollo integrados (IDE). Además, se puede utilizar con herramientas de gestión de API existentes o integrarse sobre las API REST ya implementadas.
Estos son algunos términos clave en el contexto de GraphQL:
Una característica única de GraphQL es que las respuestas reflejan la estructura de la consulta (que a su vez está definida por el esquema), lo que simplifica el análisis sintáctico para el cliente, ya que el formato de la respuesta del servidor es completamente predecible.
La naturaleza jerárquica de GraphQL refleja las relaciones entre objetos y se adapta bien a interfaces de usuario jerárquicas. Además, está fuertemente tipado, lo que implica que cada nivel de la consulta corresponde a un tipo, y esos tipos definen un conjunto de campos. Esto es similar a SQL, donde se generan mensajes de error descriptivos antes de que se complete una consulta.
Las funciones de resolución son los componentes arquitectónicos clave que conectan los campos de GraphQL, las aristas, las mutaciones, las consultas y las suscripciones con las fuentes de datos (y microservicios).
Puede aprender a crear funciones de resolución para fuentes de datos de AWS en este tutorial de GraphQL.
Una cosa que hace que las consultas GraphQL sean únicas son las respuestas reflejadas. Los datos devueltos de una consulta se vuelven predecibles, porque sabes que coincidirán con la forma de la solicitud de la API. Cuando la forma de los datos devueltos sigue la consulta del cliente, los servidores se simplifican.
Una de las principales ventajas de GraphQL es que dispone de extensiones para proporcionar funciones que no están disponibles en REST. Otras ventajas de GraphQL son las siguientes.
Un esquema GraphQL establece una única fuente de verdad en las aplicaciones GraphQL, pues proporciona una ubicación principal donde se describen todos los datos. Mientras que el esquema GraphQL se define generalmente en el servidor, los clientes todavía pueden consultar y escribir datos basados en el esquema.
En las arquitecturas REST, la sobrecarga puede convertirse rápidamente en un problema: la aplicación (back-end) define los datos disponibles para cada recurso y los devuelve todos en su respuesta, incluso si el cliente (front-end) solo necesita un único elemento. Las llamadas GraphQL se producen en un único viaje y proporcionan a los clientes los datos solicitados sin sobrecarga.
Debido a que los tipos de datos están fuertemente definidos, la comunicación entre el cliente y el servidor es más clara en GraphQL que en REST. Esta estructura subyacente también significa que no se necesitan clientes complejos para llamar a un servidor GraphQL. Para obtener más información, y para ver el código en acción, lea acerca de los clientes y servidores en la página oficial de GraphQL.
La federación de API, un conjunto de principios y herramientas de diseño, permite exponer servicios dentro de un contexto delimitado como una API coherente para los usuarios, mientras facilita la evolución de los servicios dentro de ese contexto sin restricciones. GraphQL ofrece un enfoque para federar toda la API, permitiendo su evolución sin romper las consultas previas, lo que la hace escalable. Esta capacidad de escalabilidad es una de las razones por las que GraphQL es utilizado por muchas empresas.
La naturaleza introspectiva de GraphQL permite recuperar el esquema GraphQL desde una API GraphQL. Los clientes también pueden solicitar una lista de los tipos de datos disponibles, lo que resulta ideal para generar documentación automáticamente y para probar o recuperar esquemas de múltiples microservicios.
Aunque existen muchas razones para adoptar GraphQL, también es importante considerar algunas desventajas. Por ejemplo, no todo está listo para usar: se requieren bibliotecas especiales para consumir la API de otros servicios. Además, en general, GraphQL requiere un soporte de herramientas más robusto que REST.
Los contras de GraphQL en comparación con REST son los siguientes.
Para los desarrolladores acostumbrados a las API REST, GraphQL conlleva una curva de aprendizaje más pronunciada. También puede cambiar el flujo de trabajo: los equipos de API que utilizan GraphQL también deben escribir esquemas GraphQL mantenibles. Dicho esto, si se empieza de cero, GraphQL puede ser fácil de aprender y utilizar porque las solicitudes y las respuestas tienen la misma estructura.
GraphQL puede requerir nuevas estrategias de gestión de API, mientras que las API REST tienden a encajar en los modelos de gestión de API existentes. Es importante tener esto en cuenta, ya que añadir una nueva estrategia de gestión de API puede aumentar el gasto total.
El almacenamiento en caché en GraphQL es más complejo que en REST, donde las solicitudes suelen utilizar métodos HTTP bien definidos (GET, POST, PUT o DELETE). En GraphQL, una solicitud estándar es un POST, lo cual no es fácilmente almacenable en caché a nivel HTTP. Además, el hecho de que GraphQL tenga un único punto de conexión significa que la URL de ese punto de conexión puede devolver múltiples respuestas variables, lo cual dificulta el almacenamiento en caché (es ideal para la obtención de datos, pero problemático para el almacenamiento). Los desarrolladores de servidores se enfrentan entonces a diferentes consultas, aunque cada una opere dentro del mismo objeto. A pesar de esto, muchas bibliotecas de GraphQL incluyen mecanismos de almacenamiento en caché listos para usar.