¿Qué es la federación GraphQL?

La federación divide el esquema (el contrato entre las operaciones de back-end y front-end) en componentes y microservicios más manejables, lo que permite a los equipos crear, implementar y gestionar partes de un esquema de forma independiente, al tiempo que se mantiene un gráfico de datos unificado con el que interactúan los clientes. 

En un entorno GraphQL federado, una pasarela GraphQL integra múltiples esquemas (también llamados subgrafos o servicios) en un único grafo (o enrutador). Cada subgrafo define una parte del esquema general y gestiona la lógica empresarial y la recuperación de datos para sus propios tipos y campos. A continuación, la pasarela une los subgrafos independientes en un supergrafo, lo que permite a los clientes consultar fuentes de datos de distintos servicios como si interactuaran con un único esquema GraphQL.

Antes de la federación, uno de los principales métodos para combinar múltiples esquemas GraphQL era la unión de esquemas, en la que diferentes esquemas y solucionadores se combinaban manualmente. Los desarrolladores tenían que definir cómo se combinaban los esquemas y cómo se unían los datos. Y aunque la unión de esquemas ofrecía una solución unificadora para los esquemas GraphQL, también era compleja y propensa a errores, lo que dificultaba su gestión.

Para abordar estos problemas y agilizar los procesos de unión de esquemas, los ingenieros de Apollo, una implementación de GraphQL para la ingeniería de productos y aplicaciones, desarrollaron la federación Apollo. La federación Apollo introdujo las palabras clave “key”, “external”, “requires” y “extends” ("clave", "externo/a", "requiere" y "extiende", respectivamente) para definir las conexiones entre tipos en diferentes servicios. Las nuevas funciones de referencias cruzadas permitieron a los desarrolladores utilizar una pasarela Apollo para construir un gráfico de datos cohesivo sin depender de una lógica de unión demasiado compleja.

Sin embargo, la federación Apollo GraphQL no era solo un nuevo conjunto de herramientas y bibliotecas. También era una especificación del sistema que describía la arquitectura y el modo en que los servicios pueden comunicarse para formar un grafo distribuido. Esto permitió que otras implementaciones y herramientas adoptaran los principios de federación y ayudó a establecer un estándar para construir API GraphQL federadas.

Desde su introducción, la federación GraphQL ha experimentado numerosas mejoras. La federación gestionada, por ejemplo, puede facilitar la recopilación de métricas y permitir actualizaciones automáticas de la pasarela cuando cambian los subgrafos, todo ello sin intervención manual ni tiempo de inactividad del sistema.

Los avances también incluyen el desarrollo de Federation 2¹, una innovación que simplificó la fusión de esquemas entre servicios y la ejecución de consultas, aumentó la modularidad para un mayor control sobre la composición del esquema y mejoró la visibilidad de errores para facilitar el seguimiento y la depuración.

La federación Apollo supuso un avance significativo para la creación de ecosistemas de API racionalizados, y sigue siendo una opción para las empresas que desean implementar arquitecturas de TI federadas.

Aun así, un enfoque de federación basado en Apollo encierra a los desarrolladores en una implantación de un único proveedor, ya que los entornos federados Apollo sólo pueden aceptar directivas y tipos definidos por Apollo de tecnologías backend Apollo o compatibles con Apollo. En otras palabras, la federación Apollo a menudo limita la flexibilidad del sistema, incluso cuando surgen nuevas tecnologías.

Los desarrolladores que busquen optimizar la flexibilidad manteniendo la funcionalidad de capa unificada de la federación Apollo podrían preferir la federación abierta. Los enfoques de federación abierta permiten a los sistemas combinar datos de cualquier proveedor o tipo de API, incluidas las API que no son GraphQL. Con herramientas como IBM API Connect, las empresas pueden personalizar y escalar sus activos de TI sin restricciones de compatibilidad y seguir adoptando innovaciones de diversas comunidades tecnológicas.

GraphQL ayuda a los clientes a solicitar exactamente los datos que necesitan sin subaprovisionar o sobreaprovisionar los recursos, por lo que es una gran opción para las empresas que buscan optimizar la eficiencia operativa.

Dada su flexibilidad, no es de extrañar que GraphQL sea un lenguaje de consulta y tiempo de ejecución de API cada vez más popular.² Sin embargo, a medida que las aplicaciones web y móviles se vuelven más sofisticadas, implementar un único servidor GraphQL monolítico (y todas sus dependencias) puede resultar insostenible. Federation simplifica los ecosistemas GraphQL ayudando a que subgrafos dispares funcionen juntos como un servicio GraphQL cohesivo.

La implementación de una arquitectura GraphQL federada implica los siguientes procesos clave.

Definir esquemas de subgrafos implica identificar los límites del dominio y decidir cómo deben interactuar esos límites. 

En una arquitectura federada, cada esquema de subgrafos representa una parte específica del grafo de datos global; contiene tipos, configuraciones, consultas, mutaciones y suscripciones que se aplican a un servicio o dominio. Un servicio de producto, por ejemplo, puede tener un esquema de subgrafos que incluya tipos como producto y reseña, mientras que un servicio de usuario puede tener tipos de usuario y perfil .

Los esquemas de subgrafos se definen de forma muy similar a un esquema GraphQL estándar, pero añadiendo directivas específicas de la federación. Las directivas de federación proporcionan instrucciones sobre cómo un sistema extiende entidades entre esquemas y cómo la pasarela debe resolver campos específicos entre servicios. También definen claves para referenciar entidades.

Por ejemplo, la directiva @key especifica los campos que identifican un tipo en los gráficos federados; cuando se implementa, esta directiva solicita a la pasarela que recupere una entidad del servicio que posee el tipo especificado. La directiva @extends indica que un tipo definido en un esquema subgráfico extiende un tipo que se origina en otro, facilitando la extensión del tipo (con campos adicionales) en otro servicio.

Los servicios de subgrafos son servicios back-end que implementan la lógica de negocio para las correspondientes APIs de subgrafos. Cada servicio de subgrafos define su parte del grafo de datos y gestiona las consultas y mutaciones relacionadas con su dominio. Sus respectivos solucionadores obtienen los datos asociados de las fuentes de datos, bases de datos o API REST apropiadas.

Los servicios de subgrafos también revelan sus endpoints GraphQL a la pasarela de federación, que los utiliza para componer el esquema federado general. Tenga en cuenta que estos servicios pueden escribirse en cualquier lenguaje de programación, siempre que sea compatible con GraphQL.

Las pasarelas de federación orquestan la composición de esquemas y la planificación de consultas. Con la ayuda de los servidores de federación, las pasarelas disfrazan los servicios de subgrafos individuales, presentando una API unificada al cliente.

Para configurar una pasarela de federación, los equipos suelen especificar la ubicación de cada servicio de subgrafos y configurar la infraestructura necesaria para la obtención de esquemas, la planificación de consultas, la ejecución y la gestión de errores. Una vez instalada, la pasarela obtendrá continuamente los esquemas de los servicios de subgrafo para asegurarse de que dispone de la versión más reciente del esquema federado.

Una vez configurados los servicios de subgrafos y la pasarela de federación, los administradores implementan todo el sistema. Esto incluye el aprovisionamiento de hardware y recursos en la nube, la configuración de canales de implementación, la monitorización del rendimiento del sistema y la garantía de una alta disponibilidad de recursos.

No es de extrañar que una monitorización coherente en tiempo real sea vital para optimizar un entorno GraphQL federado. Una monitorización atenta permite a los equipos detectar y resolver cuellos de botella en el rendimiento, errores del sistema y tiempos de inactividad imprevistos antes de que generen problemas mayores. La monitorización también permite realizar un seguimiento del estado de los servicios de subgrafos y de la pasarela de federación.

La federación GraphQL representa un avance significativo en el desarrollo de API GraphQL para sistemas distribuidos a gran escala. Permite a los equipos trabajar en diferentes partes de un esquema GraphQL de forma independiente al tiempo que integran su trabajo de manera fluida en una API unificada, todo ello sin interrumpir la experiencia del usuario final.

La federación GraphQL también tiene una amplia gama de casos de uso (desde la implementación de arquitecturas de microservicios y el almacenamiento en caché hasta el desarrollo de productos y los conocimientos sobre operaciones) y ha sido adoptada por empresas como Netflix, Airbnb, GitHub y Expedia.

La federación GraphQL también facilita: