¿Qué es la federación de 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, desplegar y gestionar partes de un esquema de forma independiente, al tiempo que mantienen un gráfico de datos unificado para que los clientes interactúen. 

En un entorno GraphQL federado, una puerta de enlace GraphQL integra múltiples esquemas—también llamados subgrafos o servicios—en un solo gráfico (o enrutador). Cada subgrafo define parte del esquema general y maneja la lógica de negocio y la recuperación de datos para sus propios tipos y campos. Luego, la puerta de enlace une subgrafos independientes en un supergrafo, lo que permite a los clientes consultar fuentes de datos en todos los servicios como si interactuaran con un único esquema GraphQL.

Antes de la federación, uno de los métodos principales para combinar múltiples esquemas GraphQL era la unión de esquemas, donde diferentes esquemas y reductores se combinan manualmente. Requería que los desarrolladores definieran cómo se fusionan los esquemas y cómo se unirían los datos. Y aunque la unión de esquemas ofrecía una solución unificadora para el esquema GraphQL, también era compleja y propensa a errores, lo que dificultaba su gestión.

Para abordar estos problemas y optimizar los procesos de unión de esquemas, los ingenieros detrás de Apollo—una implementación de GraphQL para ingeniería de productos y aplicaciones—desarrollaron la federación Apollo. La federación Apollo introdujo las palabras clave "clave", "externo", "requiere" y "extiende" para definir las conexiones entre tipos en diferentes servicios. Las nuevas funciones de referencias cruzadas permitieron a los desarrolladores emplear una puerta de enlace Apollo para crear 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 cómo los servicios pueden comunicarse para formar un gráfico distribuido. Esto permitió que otras implementaciones y herramientas adoptaran los principios de federación y ayudó a establecer un estándar para crear APIs de GraphQL federadas.

Desde su introducción, la federación GraphQL experimentó numerosas mejoras. La federación gestionada, por ejemplo, puede facilitar la recopilación de métricas y permitir actualizaciones automáticas de la puerta de enlace cuando cambian los subgráficos, todo 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 representó un avance significativo para crear ecosistemas de API optimizados, y sigue siendo una opción para las empresas que buscan desplegar arquitecturas de TI federadas.

Aún así, un enfoque de federación basado en Apollo bloquea a los desarrolladores en una implementación de un solo proveedor, ya que los entornos federados de Apollo solo pueden aceptar directivas y tipos definidos por Apollo de tecnologías Apollo o de backend 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 buscan optimizar la flexibilidad mientras mantienen la funcionalidad de capa unificada de la federación Apollo podrían preferir la federación abierta. Los enfoques de federación abierta permiten que los sistemas combinen datos de cualquier proveedor o tipo de API, incluyendo las API que no son de GraphQL. Mediante el uso de herramientas como IBM API Connect, las empresas pueden personalizar y escalar sus activos de TI sin restricciones de compatibilidad y continuar adoptando innovaciones de una variedad de comunidades tecnológicas.

GraphQL ayuda a los clientes a aplicar exactamente los datos que necesitan sin aprovisionar recursos de forma insuficiente o excesiva, lo que lo convierte en una excelente opción para las empresas que buscan optimizar la eficiencia operativa.

Dada su flexibilidad, no sorprende que GraphQL sea un lenguaje de consulta y un tiempo de ejecución cada vez más populares para las APIs.² Sin embargo, a medida que las aplicaciones de sitio web y celulares se vuelven más sofisticadas, el despliegue de un único servidor GraphQL monolítico (y todas sus dependencias) puede volverse insostenible. La federación simplifica los ecosistemas GraphQL al ayudar a los subgrafos dispares a trabajar 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 subgrafo representa una parte específica del grafo de datos general; contiene tipos, configuraciones, consultas, mutaciones y suscripciones que se aplican a un servicio o dominio. Un servicio de producto, por ejemplo, podría tener un esquema de subgrafo que incluya tipos como producto y revisión, mientras que un servicio de usuario podría tener tipos de usuario y perfil .

Los esquemas de subgrafo se definen de manera muy similar a un esquema GraphQL estándar, pero con la adición de directivas específicas de la federación. Las directivas de la federación proporcionan instrucciones sobre cómo un sistema extiende entidades a través de esquemas y cómo la puerta de enlace debe resolver campos específicos en todos los servicios. También definen claves para entidades de referencia.

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

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

Los servicios de subgrafos también revelan sus endpoints GraphQL a la puerta de enlace de federación, que los emplea para componer el esquema federado general. Tenga en cuenta que estos servicios se pueden escribir en cualquier lenguaje de programación, suponiendo que el lenguaje admita GraphQL.

Las puertas de enlace de la federación orquestan la composición del esquema y la planeación de consultas. Con la ayuda de los servidores de la federación, las puertas de enlace disfrazan los servicios de subgrafos individuales, presentando una API unificada al cliente.

Para configurar una pasarela de la 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 planeación de consultas, la ejecución y la gestión de errores. Cuando esté en funcionamiento, la pasarela obtendrá continuamente los esquemas de los servicios de subgrafos para cerciorarse de que dispone de la versión más reciente del esquema federado.

Cuando se configuran los servicios de subgrafos y la puerta de enlace de la federación, los administradores despliegan todo el sistema. Esto incluye el aprovisionamiento de hardware y recursos en la nube, la configuración de canalizaciones de despliegue, la supervisión del rendimiento del sistema y la garantía de una alta disponibilidad de recursos.

No debería sorprender que el monitoreo constante en tiempo real sea vital para optimizar un entorno GraphQL federado. El monitoreo vigilante permite a los equipos detectar y resolver cuellos de botella en el rendimiento, errores del sistema y tiempo de inactividad no planificado antes de que creen problemas mayores. La supervisión también permite el seguimiento del estado de los servicios de subgrafos y la puerta de enlace de federación.

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

La federación GraphQL también tiene una amplia gama de casos de uso, desde el despliegue en caché de la arquitectura de microservicios hasta el desarrollo de productos e insights sobre operaciones, y ha sido adoptada por empresas como Netflix, Airbnb, GitHub y Expedia.

La federación GraphQL también facilita: