Graphql – Cambiando y Mejorando la Forma en que las Aplicaciones se Comunican

No pasará mucho tiempo antes de que la próxima generación esté comprando criptomonedas y verificando su saldo de unidad de confianza en el lobby de Fortnite entre partidas. Esto será posible gracias a muchos avances tecnológicos.

El que estamos discutiendo hoy es la forma en que se transfiere la data (leer, actualizar, agregar/eliminar) entre aplicaciones y las empresas que las poseen. Las interfaces de programación de aplicaciones (API) son la arquitectura que define esta comunicación de datos y, a medida que estos estándares se han desarrollado, los requisitos de procesamiento y almacenamiento de datos se han vuelto menos arduos.

El líder en la manada en términos de “uso de recursos ‘ligero'” es GraphQL, un lenguaje de consulta y manipulación de datos de código abierto. La base de su ecosistema es su especificación y una colección de herramientas que se han creado alrededor de ella.

No es nuevo – el tiempo pasa rápido. Facebook lo desarrolló en 2012 y lo usó solo internamente para el desarrollo de aplicaciones móviles. En 2015 se “abrió” y hoy es atendido por la Fundación GraphQL (https://graphql.org/foundation/) que supervisa su desarrollo posterior.

Así que, ¿por qué estoy escribiendo sobre esto ahora? Una hoja de ruta típica para la adopción tecnológica seguirá las siguientes etapas: 1) aficionados/proyectos personales, 2) implementación en múltiples lenguajes, 3) implementaciones en startups y empresas pequeñas, 4) empresas de tamaño mediano y utilizadas en el desarrollo de productos, 5) grandes corporaciones y gigantes tecnológicos.

GraphQL ha alcanzado el nivel 5. Actualmente, es utilizado por GitHub, Pinterest, Shopify, Microsoft, por nombrar algunos, y más recientemente, a partir de marzo de 2022, Salesforce.

Al buscar una forma de recuperar datos de manera más eficiente desde Salesforce, me encontré con su documentación de GraphQL y comencé a leer y a buscar formas de implementarlo.

¿Cómo difiere de una API REST tradicional?

• Una de las principales ventajas es que con GraphQL puedes consultar y solo obtener los datos específicos. Si solo quieres dos campos relacionados con un incidente de cliente específico, entonces eso es lo que obtienes. Una API REST tradicional te devolvería todos los campos asociados con el incidente. Eso podría ser 100+ campos. Ahora debes hacer algo con todos esos datos que no querías desde el principio. Esto se conoce como exceso de datos (la subrecopilación también es un problema).
• Lo anterior hace que GraphQL sea más rápido que otras metodologías de API al devolver datos.
• GraphQL es un lenguaje fuertemente tipado que, entre otras cosas, significa que los errores de código se detectan antes de que se ejecute el programa y no durante su ejecución.
• Se han construido una gran cantidad de herramientas alrededor de GraphQL que lo han hecho muy amigable para los desarrolladores.
• GraphQL tiene un solo punto de conexión, en lugar de la API REST que tiene múltiples puntos de conexión. Esto significa que todos tus datos se pueden recuperar en una sola solicitud.

Los dos lados de la moneda: solicitante (cliente) y proveedor (host de GraphQL)

He estado mirando GraphQL hasta ahora desde la perspectiva de la “solicitud” de datos. Donde una empresa como Salesforce o Microsoft ha configurado una API de GraphQL que puedes utilizar para consultar y manipular datos (leer, actualizar, agregar).

Como ejemplo, si queremos incluir datos de Salesforce relacionados con incidentes de clientes en un portal de clientes, la forma más eficiente de hacerlo sería solicitar los datos exactos que estamos buscando a través de una consulta de GraphQL desde el portal al servidor de GraphQL de Salesforce. Obtendrás exactamente los datos que quieres, sin subrecopilación ni exceso de datos, y como resultado, no se requiere procesamiento o almacenamiento de datos adicionales.

El otro lado de la moneda es la organización que configura la arquitectura de GraphQL para que tus clientes tengan un método eficiente para acceder a los datos que desean.

Al construir la API de GraphQL, una organización está creando un modelo que integra todos sus sistemas en uno solo. Unifica estos sistemas y, una vez hecho, elimina la complejidad del sistema subyacente. Una vez que se completa el trabajo, consultar los datos se vuelve fluido a través de la API.

Al comparar aplicaciones o proveedores, miro qué funciones me ofrecen para recuperar mis datos de ellos. No quiero tener que enviarles un correo electrónico o depender de informes predefinidos rígidos. Quiero poder “conectar” mis datos consultándolos de manera flexible y oportuna. Si se reduce a dos aplicaciones/proveedores y están igualmente equiparados en otros puntos de comparación, y uno ofrece una API REST o una API de GraphQL, sin duda elegiré la que tenga la API.