Integración de GraphQL de microservicios con AWS AppSync Merged API - Práctica de desarrollo distribuido por equipos

Explicamos cómo integrar en un único endpoint las API GraphQL que varios equipos desarrollan / despliegan de forma independiente. También presentamos formas de evitar conflictos de esquema y el diseño de la estrategia de autenticación.

Unos 8 min de lecturaÚltima actualización: 2026-10-31

La necesidad de Merged API

Cuando varios equipos desarrollan API GraphQL en una arquitectura de microservicios, el frontend tiene que enviar solicitudes a varios endpoints, lo que aumenta la complejidad en el lado del cliente. Merged API aborda este problema integrando varias API de origen (source API) en un único endpoint. La User API del equipo de usuarios, la Order API del equipo de pedidos y la Product API del equipo de productos se desarrollan / despliegan de forma independiente, mientras que el frontend puede acceder a ellas a través de un único endpoint GraphQL. A diferencia de la agregación de API basada en REST como API Gateway, la integración se produce a nivel del esquema de GraphQL, por lo que las consultas entre servicios también se pueden ejecutar en una sola solicitud.

Diseño de las API de origen y despliegue independiente

Cada equipo desarrolla una API de AppSync independiente como API de origen. El esquema, los resolvers y las fuentes de datos se gestionan por cada API de origen, y cada equipo puede desplegar / actualizar su propia API de forma independiente. Las actualizaciones de una API de origen se reflejan en la Merged API si se ha configurado la combinación automática, y en el caso de la combinación manual, el propietario de la API de origen ejecuta la combinación. Los conflictos de esquema (campos de Query con el mismo nombre, definiciones de tipos con el mismo nombre) se detectan en el momento de la combinación y se notifican como errores. Para evitar conflictos, existe el diseño de acordar de antemano entre los equipos las convenciones de nomenclatura del esquema y usar prefijos a modo de espacio de nombres (user_, order_), o de gestionar las definiciones de tipos comunes como un esquema compartido.

Estrategia de autenticación

En el nivel de la Merged API se configura el método de autenticación predeterminado (grupos de usuarios de Cognito, IAM, claves de API, autorizadores de Lambda). Se pueden configurar métodos de autenticación adicionales para cada API de origen y aplicar la autenticación de la API de origen a campos específicos. Por ejemplo, es posible una configuración en la que la autenticación predeterminada de la Merged API se establece en Cognito, mientras que se añade la autenticación de IAM en el nivel de la API de origen para las Mutations destinadas a los administradores. Con la directiva @aws_auth se controla la autenticación a nivel de campo, y se pueden mostrar campos específicos solo a grupos específicos de Cognito.

Precios y limitaciones de Merged API

El precio de Merged API es el mismo que el de una API de AppSync normal, y las consultas / mutaciones cuestan aproximadamente 4.00 USD por millón de solicitudes (a fecha de agosto de 2026). La Merged API en sí no tiene cargos adicionales, pero hay un límite en el número de API de origen (10 de forma predeterminada), y en entornos de microservicios de gran escala es necesario solicitar un aumento del límite. Cuando el resolver de una API de origen llama a Lambda, el precio de Lambda se cobra a la cuenta de la API de origen. Si habilita la caché de la Merged API, se almacenan en caché los resultados de las consultas que abarcan varias API de origen, lo que permite reducir el número de llamadas al backend.

Actualizaciones en tiempo real y suscripciones

Una de las funciones de GraphQL son las actualizaciones de datos en tiempo real mediante suscripciones. En la Merged API también se integran las suscripciones definidas por cada API de origen, y el frontend puede suscribirse a las notificaciones de actualización de varios servicios a través de un único endpoint. Como el servidor envía los cambios mediante WebSocket, se puede aprovechar para usos como el chat, las notificaciones y la actualización en directo de paneles. Desde el cliente se pueden manejar, con el mismo endpoint, las funciones en tiempo real que cada equipo ha definido de forma independiente.

Supervisión y observabilidad

En la operación de una API integrada, se comprueba qué resolver de qué API de origen es lento. Se registra el estado de ejecución de las solicitudes y de los resolvers en los registros de CloudWatch, y se visualiza con el rastreo distribuido de X-Ray cómo han pasado las solicitudes por las API de origen y los backends. Así se pueden identificar los cuellos de botella de latencia y los puntos donde se producen errores. Si se puede seguir el estado de resolución por campo, resulta más fácil aislar la causa de que una consulta concreta sea pesada. Como interviene código de varios equipos, se prepara un mecanismo que permita observar de forma transversal.

CI/CD y gestión del esquema

Como cada equipo despliega de forma independiente, se prepara un mecanismo que mantenga la coherencia del esquema. Los cambios de las API de origen se incorporan a la pipeline de CI/CD, y los conflictos de esquema en la combinación se detectan automáticamente para que los cambios incompatibles no lleguen a producción. Los equipos acuerdan las convenciones de nomenclatura y los prefijos, y los tipos compartidos se gestionan como definiciones comunes. Si se opera de forma que los cambios se apliquen después de pasar pruebas de contrato para no romper los campos de los que dependen los clientes, se puede mantener un endpoint estable incluso en el desarrollo distribuido. Gestionar las versiones del esquema como código respalda el seguimiento de los cambios y una evolución segura.

Caché y optimización del rendimiento

Las consultas que abarcan varias API de origen tienden a aumentar las llamadas al backend. Si habilita la caché de la Merged API, las respuestas de las consultas que devuelven con frecuencia el mismo resultado se conservan durante un tiempo determinado, lo que permite reducir la carga del backend y la latencia. En el diseño de los resolvers, hay que tener cuidado con el problema N+1, en el que los datos relacionados se obtienen de uno en uno y las llamadas se multiplican, y mejorar la eficiencia con un procesamiento por lotes que los obtenga en conjunto. Se puede mantener el rendimiento global diseñando cada API de origen para que devuelva los datos de forma eficiente dentro de su propio ámbito de responsabilidad y evitando que se produzcan recuperaciones excesivas en la capa de integración.

Resumen

AppSync Merged API es un servicio que integra las API GraphQL de varios equipos en un único endpoint. Ofrece al frontend un único endpoint sencillo mientras mantiene el despliegue independiente de cada equipo. Es uno de los patrones para adoptar GraphQL en una arquitectura de microservicios.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.