Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Fusión de API en AWS AppSync

A medida que se generaliza el uso de GraphQL en una organización, la facilidad de uso de las API puede afectar a su velocidad de desarrollo y viceversa. Por un lado, las organizaciones adoptan AWS AppSync GraphQL para simplificar el desarrollo de aplicaciones. Esto proporciona a los desarrolladores una API flexible que pueden usar para acceder, manipular y combinar de forma segura los datos de uno o más dominios de datos con una sola llamada a la red. Por otro lado, los equipos de una organización que son responsables de los diferentes dominios de datos combinados en un único punto final de API de GraphQL tal vez deseen tener la capacidad de crear, administrar e implementar actualizaciones de API de forma independiente unas de otras. Esto aumenta su velocidad de desarrollo.

Para resolver esta tensión, la función de API AWS AppSync combinadas permite a los equipos de diferentes dominios de datos crear e implementar de forma independiente AWS AppSync API (por ejemplo, esquemas, solucionadores, fuentes de datos y funciones de GraphQL), que luego se pueden combinar en una sola API fusionada. De este modo, las organizaciones pueden mantener una API multidominio fácil de usar y los diferentes equipos que colaboran en esa API pueden aplicar actualizaciones de la API de forma rápida e independiente.

El siguiente diagrama muestra el flujo de trabajo de las API combinadas:

Con las API combinadas, las organizaciones pueden importar los recursos de varias AWS AppSync API de origen independientes a un único punto final de API AWS AppSync combinadas. Para ello, AWS AppSync puede crear una lista de AWS AppSync API de origen y, a continuación, combinar todos los metadatos asociados a las API de origen, incluidos el esquema, los tipos, las fuentes de datos, los solucionadores y las funciones, en una nueva AWS AppSync API fusionada.

Durante las fusiones, pueden producirse conflictos de fusión debido a incoherencias en el contenido de los datos de la API de origen, como conflictos en la nomenclatura de los tipos cuando se combinan varios esquemas. En los casos de uso sencillos sin definiciones en el conflicto de las API de origen, no es necesario modificar los esquemas de las API de origen. La API combinada resultante simplemente importa todos los tipos, solucionadores, fuentes de datos y funciones de las API de origen originales. AWS AppSync Para los casos de uso complejos en los que surjan conflictos, users/teams deberán resolver los conflictos a través de varios medios. AWS AppSync proporciona a los usuarios varias herramientas y ejemplos que pueden reducir los conflictos de fusión.

Las fusiones posteriores que se configuren en AWS AppSync propagarán los cambios realizados en las API de origen a la API combinada asociada.

API fusionadas y federación

Hay muchas soluciones y patrones en la comunidad de GraphQL para combinar esquemas de GraphQL y permitir la colaboración en equipo a través de un gráfico compartido. AWS AppSync Las API combinadas adoptan un enfoque basado en el tiempo de construcción para la composición de esquemas, en el que las API de origen se combinan en una API fusionada independiente. Otra opción consiste en colocar un enrutador en tiempo de ejecución en varias API de origen o gráficos secundarios. En este enfoque, el router recibe una solicitud, hace referencia a un esquema combinado que mantiene como metadatos, construye un plan de solicitudes y, a continuación, distribuye los elementos de la solicitud en su subsistema subyacente. graphs/servers La siguiente tabla compara el enfoque basado en el tiempo de creación de la API AWS AppSync combinada con los enfoques basados en enrutadores y en tiempo de ejecución para la composición de esquemas de GraphQL:

* Las API AWS AppSync combinadas solo se pueden asociar a las API AWS AppSync de origen. Si necesitas soporte para la composición de esquemas transversales AWS AppSync y no AWS AppSync subgráficos, puedes conectar una o más API and/or combinadas de AWS AppSync GraphQL a una solución basada en enrutadores. Por ejemplo, consulta el blog de referencia para añadir las AWS AppSync API como subgráficos mediante una arquitectura basada en enrutadores con Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync

Resolución de conflictos de la API fusionada

En caso de que surja un conflicto de fusión, AWS AppSync proporciona a los usuarios varias herramientas y ejemplos para ayudar a solucionar los problemas.

Directivas de esquema de la API fusionada

AWS AppSync ha introducido varias directivas de GraphQL que pueden usarse para reducir o resolver conflictos entre las API de origen:

Para mostrar el esquema de utilidades que proporcionan las directivas, observe el siguiente ejemplo:

En este ejemplo, supongamos que queremos fusionar dos API de origen. Tenemos dos esquemas que crean y recuperan publicaciones (p. ej., publicaciones en la sección de comentarios o en las redes sociales). Suponiendo que los tipos y los campos sean muy similares, la probabilidad de que surjan conflictos durante una operación de fusión es muy elevada. Los fragmentos siguientes muestran los tipos y campos de cada esquema.

El primer archivo, llamado Source1.graphql, es un esquema de GraphQL que permite al usuario crear Posts usando la putPost mutación. Cada Post contiene un título y un ID. El ID se utiliza para hacer referencia al User, o a la información del autor de la publicación (correo electrónico y dirección), y al Message, o la carga útil (contenido). El tipo de User se anota con la etiqueta @canonical.

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post {
    id: ID!
    title: String!
}

type Message {
   id: ID!
   content: String
}

type User @canonical {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
}

El segundo archivo, llamado Source2.graphql, es un esquema de GraphQL que hace cosas muy similares a las de. Source1.graphql Sin embargo, tenga en cuenta que los campos de cada tipo son diferentes. Al fusionar estos dos esquemas, se producirán conflictos de fusión debido a estas diferencias.

Tenga en cuenta también que Source2.graphql también contiene varias directivas para reducir estos conflictos. El tipo Post tiene anotada una etiqueta @hidden para ocultarse durante la operación de fusión. El tipo Message tiene anotada la etiqueta @renamed para cambiar el nombre del tipo a ChatMessage en caso de conflicto de nomenclatura con otro tipo Message.

# This snippet represents a file called Source2.graphql

type Post @hidden  {
    id: ID!
    title: String!
    internalSecret: String!
}

type Message @renamed(to: "ChatMessage") {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

# Stub user so that we can link the canonical definition from Source1
type User {
   id: ID!
}

type Query {
    getPost(id: ID!): Post
    getMessage(id: ID!): Message @renamed(to: "getChatMessage")
}

Cuando se produzca la fusión, el resultado generará el archivo MergedSchema.graphql:

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

# Post from Source2 was hidden so only uses the Source1 definition. 
type Post {
    id: ID!
    title: String!
}

# Renamed from Message to resolve the conflict
type ChatMessage {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

type Message {
   id: ID!
   content: String
}

# Canonical definition from Source1
type User {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
    
    # Renamed from getMessage
    getChatMessage(id: ID!): ChatMessage
}

En la fusión ocurrieron varias cosas:

También puede ocurrir que no se agreguen directivas a un tipo con conflictos. En este caso, el tipo fusionado incluirá la unión de todos los campos de todas las definiciones de origen de ese tipo. Por ejemplo, observe el siguiente caso:

Este esquema, denominado Source1.graphql, permite crear y recuperar. Posts La configuración es similar a la del ejemplo anterior, pero con menos información.

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
}

type Query {
    getPost(id: ID!): Post
}

Este esquema, denominado Source2.graphql, permite crear y recuperar Reviews (p. ej., valoraciones de películas o reseñas de restaurantes). Reviewsestán asociadas al mismo valor Post de ID. En conjunto, contienen el título, el ID de la publicación y el mensaje de carga útil de la publicación de la reseña completa.

Al fusionarse, habrá un conflicto entre los dos tipos Post. Como no hay anotaciones para resolver este problema, se lleva a cabo, de manera predeterminada, una operación de unión de los tipos en conflicto.

# This snippet represents a file called Source2.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
}

type Post  {
    id: ID!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getReview(id: ID!): Review
}

Cuando se produzca la fusión, el resultado generará el archivo MergedSchema.graphql:

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getPost(id: ID!): Post
    getReview(id: ID!): Review
}

En la fusión ocurrieron varias cosas:

Administración de solucionadores en tipos compartidos

En el ejemplo anterior, consideremos el caso en el que se Source1.graphql ha configurado un solucionador de unidadesQuery.getPost, que utiliza una fuente de datos de DynamoDB denominada. PostDatasource Este solucionador devolverá el id y el title de un tipo Post. Ahora, considere que Source2.graphql ha configurado un solucionador de canalización activadoPost.reviews, que ejecuta dos funciones. Function1tiene una fuente None de datos adjunta para realizar comprobaciones de autorización personalizadas. Function2tiene una fuente de datos de DynamoDB adjunta para consultar la reviews tabla.

query GetPostQuery {
    getPost(id: "1") {
        id,
        title,
        reviews
    }
}

Cuando un cliente ejecuta la consulta anterior en el punto final de la API combinada, el AWS AppSync servicio ejecuta primero el solucionador de unidades para Query.getPost fromSource1, que llama a DynamoDB PostDatasource y devuelve los datos de DynamoDB. A continuación, ejecuta el solucionador de canalizaciones de Post.reviews, en el cual Function1 ejecuta una lógica de autorización personalizada y Function2 devuelve las revisiones en función del id encontrado en $context.source. El servicio procesa la solicitud como una sola ejecución de GraphQL, y esta solicitud sencilla requiere un único token de solicitud.

Gestión de conflictos de solucionadores en tipos compartidos

Pensemos en el siguiente caso, Query.getPost en el que también implementamos un solucionador para proporcionar varios campos a la vez además del solucionador de campos en el que se encuentra el solucionador de campos. Source2 Source1.graphqlpuede tener este aspecto:

# This snippet represents a file called Source1.graphql

type Post  {
    id: ID!
    title: String!
    date: AWSDateTime!
}

type Query {
    getPost(id: ID!): Post
}

Source2.graphqlpuede tener este aspecto:

# This snippet represents a file called Source2.graphql

type Post  {
  id: ID!
  content: String!
  contentHash: String! 
  author: String! 
}

type Query {
    getPost(id: ID!): Post
}

Si se intenta fusionar estos dos esquemas, se generará un error de combinación, ya que las API AWS AppSync combinadas no permiten adjuntar varios solucionadores de código fuente al mismo campo. Para resolver este conflicto, puede implementar un patrón de resolución de campos que requiera Source2.graphql agregar un tipo diferente que defina los campos que le pertenecen del Post tipo. En el siguiente ejemplo, agregamos un tipo denominadoPostInfo, que contiene los campos de contenido y autor que se resolverán Source2.graphql. Source1.graphqlimplementará el solucionador adjuntoQuery.getPost, mientras que ahora Source2.graphql adjuntará un solucionador Post.postInfo para garantizar que todos los datos se puedan recuperar correctamente:

type Post  {
  id: ID!
  postInfo: PostInfo
}

type PostInfo {
   content: String!
   contentHash: String!
   author: String!
}

type Query {
    getPost(id: ID!): Post
}

Si bien la resolución de este tipo de conflicto requiere que se reescriban los esquemas de las API de origen y, posiblemente, que los clientes cambien sus consultas, la ventaja de este enfoque es que la propiedad de los solucionadores fusionados queda clara entre los equipos de origen.

Administrar la autorización en los campos compartidos

Cuando dos o más API de origen declaran el mismo campo, la combinación combina las directivas de autorización de cada declaración. Luego, los clientes pueden acceder al campo fusionado a través de cualquiera de esos modos de autorización. Si una API de origen declara un campo con @aws_iam y otra API de origen declara el mismo campo con@aws_api_key, el campo fusionado acepta cualquiera de los dos y un cliente que solo tenga una clave de API puede invocarla.

Para mantener la autorización de un campo tal como la define tu API de origen, anota el campo con la directiva de autorización que necesitas @canonical y declara en el propio campo. En el siguiente ejemplo, Source1.graphql es el propietario del solucionador protectedRead y necesita la autorización de IAM:

# This snippet represents a file called Source1.graphql

type Query {
    protectedRead: String @aws_iam @canonical
}

# This snippet represents a file called Source2.graphql

type Query {
    protectedRead: String @aws_api_key
}

Cuando se produce la combinación, la definición de Source1.graphql tiene prioridad:

# This snippet represents a file called MergedSchema.graphql

type Query {
    protectedRead: String @aws_iam
}

Sin la anotación @canonical, el campo fusionado sería. protectedRead: String @aws_api_key @aws_iam Un cliente que solo posea la clave de API de la API fusionada puede invocarla.

Si tu API de origen es la propietaria del solucionador del campo, anota el campo en esa API de origen, ya que el solucionador devuelve los datos.

Se aplican dos condiciones:

Declare la directiva de autorización sobre el terreno

@canonical conserva el campo tal como se declaró. Un campo con la anotación @canonical sin una directiva de autorización propia adopta el modo de autorización principal de la API de origen, que puede ser más permisivo de lo que pretendes.

Anota un campo en una sola API de origen

Si dos API de origen anotan el mismo campo como canónico, la combinación falla y se produce el error. Multiple subschemas cannot declare the same field as canonical

Aplica @canonical a nivel de campo en lugar de a nivel de tipo para restringir la autorización en campos específicos. Esto aún permite que otras API de origen aporten campos adicionales al mismo tipo. Esta guía se aplica a los campos de QueryMutation, y así Subscription como a los campos de los tipos de objetos.

Si no quieres que ningún campo aparezca en la API combinada, usa @hidden en su lugar. Para obtener más información, consulte Directivas de esquema de la API fusionada.

Configuración de esquemas

Hay dos partes responsables de configurar los esquemas para crear una API fusionada:

Como el esquema de la API fusionada se crea a partir de los esquemas de sus API de origen asociadas, este es de solo lectura. Esto significa que los cambios en el esquema deben iniciarse en las API de origen. En la AWS AppSync consola, puedes cambiar entre tu esquema fusionado y los esquemas individuales de las API de origen incluidas en tu API fusionada mediante la lista desplegable situada encima de la ventana Esquema.

Configuración de modos de autorización

Hay varios modos de autorización disponibles para proteger su API fusionada. Para obtener más información sobre los modos de autorización AWS AppSync, consulta Autorización y autenticación.

Los modos de autorización siguientes están disponibles para su uso con las API fusionadas:

Los modos de autorización de una API fusionada los configura el propietario de la API fusionada. Al llevar a cabo una operación de fusión, la API fusionada debe incluir el modo de autorización principal configurado en una API de origen, ya sea como su propio modo de autorización principal o como modo de autorización secundario. De lo contrario, será incompatible, la operación de fusión producirá un error y se generará un conflicto. Cuando se utilizan directivas de autenticación múltiple en las API de origen, el proceso de fusión puede fusionar automáticamente estas directivas en el punto de conexión unificado. Si el modo de autorización principal de la API de origen no coincide con el modo de autorización principal de la API fusionada, este agregará automáticamente estas directivas de autorización para garantizar que el modo de autorización de los tipos de la API de origen sea coherente.

Configuración de roles de ejecución

Al crear una API fusionada, es necesario definir un rol de servicio. Una función de AWS servicio es una función de administración de acceso e AWS identidad (IAM) que utilizan los AWS servicios para realizar tareas en su nombre.

En este contexto, su API fusionada debe ejecutar solucionadores que accedan a los datos de orígenes de datos configurados en sus API de origen. El rol de servicio necesario para ello es mergedApiExecutionRole, y este debe tener acceso explícito para ejecutar solicitudes en las API de origen incluidas en la API fusionada mediante el permiso appsync:SourceGraphQL de IAM. Durante la ejecución de una solicitud de GraphQL, el AWS AppSync servicio asumirá este rol de servicio y lo autorizará a realizar la appsync:SourceGraphQL acción.

AWS AppSync permite permitir o denegar este permiso en campos específicos de nivel superior de la solicitud, por ejemplo, cómo funciona el modo de autorización de IAM para las API de IAM. En el caso de los campos que no son de nivel superior, AWS AppSync requiere que definas el permiso en el propio ARN de la API de origen. Para restringir el acceso a campos específicos que no son de nivel superior en la API fusionada, le recomendamos implementar una lógica personalizada en su Lambda u ocultar los campos de la API de origen de la API fusionada mediante la directiva @hidden. Si quiere permitir que el rol realice todas las operaciones de datos dentro de una API de origen, puede agregar la política que se indica a continuación. Tenga en cuenta que la primera entrada de recursos permite el acceso a todos los campos de nivel superior y la segunda incluye los solucionadores secundarios que autorizan en el propio recurso de la API de origen:

JSON

{
    "Version":"2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/*", 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

Si quiere limitar el acceso únicamente a un campo de nivel superior específico, puede usar una política como esta:

JSON

{
    "Version":"2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/types/Query/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

También puedes usar el asistente de creación de API de AWS AppSync consola para generar un rol de servicio que permita a la API fusionada acceder a los recursos configurados en las API de origen que están en la misma cuenta que la API fusionada. En el caso de que las API de origen no estén en la misma cuenta que la API fusionada, primero debes compartir tus recursos mediante AWS Resource Access Manager (AWS RAM).

Configurar las API fusionadas entre cuentas mediante AWS RAM

Al crear una API combinada, si lo desea, puede asociar las API de origen de otras cuentas que se hayan compartido mediante AWS Resource Access Manager (AWS RAM). AWS RAM le ayuda a compartir sus recursos de forma segura entre AWS cuentas, dentro de su organización o unidades organizativas (OU) y con los roles y usuarios de IAM.

AWS AppSync se integra con AWS RAM el fin de permitir la configuración y el acceso a las API de origen en varias cuentas desde una única API combinada. AWS RAM permite crear un recurso compartido o un contenedor de recursos y los conjuntos de permisos que se compartirán para cada uno de ellos. Puede añadir AWS AppSync API a un recurso compartido en AWS RAM. Dentro de un recurso compartido, AWS AppSync proporciona tres conjuntos de permisos diferentes que se pueden asociar a una AWS AppSync API en la RAM:

AWS AppSync también admite los permisos gestionados por el cliente. Si uno de los permisos AWS gestionados proporcionados no funciona, puedes crear tu propio permiso gestionado por el cliente. Customer-managed Los permisos son permisos gestionados que tú creas y mantienes especificando con precisión qué acciones se pueden realizar en qué condiciones y con recursos compartidos. AWS RAM AWS AppSync le permite elegir entre las siguientes acciones al crear su propio permiso:

Cuando hayas compartido correctamente una API de origen o una API fusionada AWS RAM y, si es necesario, hayas aceptado la invitación a compartir recursos, esta aparecerá en la AWS AppSync consola cuando crees o actualices las asociaciones de API de origen en tu API fusionada. También puedes enumerar todas las AWS AppSync API que se han compartido AWS RAM con tu cuenta, independientemente del conjunto de permisos. Para ello, llama a la ListGraphqlApis operación proporcionada por ella AWS AppSync y utiliza el filtro de OTHER_ACCOUNTS propietario.

Fusión

Administración de fusiones

Las API combinadas están diseñadas para respaldar la colaboración en equipo en un AWS AppSync punto final unificado. Los equipos pueden desarrollar por su cuenta sus propias API de origen de GraphQL aisladas en el backend mientras el servicio AWS AppSync gestiona la integración de los recursos en el punto de conexión único de la API fusionada para reducir la fricción en la colaboración y reducir los plazos de desarrollo.

Auto-merges

Las API de origen asociadas a la API AWS AppSync fusionada se pueden configurar para que se fusionen automáticamente (fusión automática) en la API fusionada después de realizar cualquier cambio en la API de origen. Esto garantiza que los cambios en la API de origen siempre se propaguen al punto de conexión de la API fusionada en segundo plano. Cualquier cambio en el esquema de la API de origen se actualizará en la API fusionada siempre y cuando no genere un conflicto de fusión con una definición existente en la API fusionada. Si la actualización de la API de origen actualiza un solucionador, un origen de datos o una función, también se actualizará el recurso importado. Cuando se introduce un nuevo conflicto que no se puede resolver automáticamente (resolución automática), se rechaza la actualización del esquema de la API fusionada debido a un conflicto no admitido durante la operación de fusión. El mensaje de error está disponible en la consola para cada asociación de la API de origen cuyo estado sea MERGE_FAILED. También puedes inspeccionar el mensaje de error llamando a la GetSourceApiAssociation operación de una asociación de API de origen determinada mediante el AWS SDK o mediante la AWS CLI de la siguiente manera:

aws appsync get-source-api-association --merged-api-identifier <Merged API ARN> --association-id <SourceApiAssociation id>

Esto generará un resultado con el formato siguiente:

{
    "sourceApiAssociation": {
        "associationId": "<association id>",
        "associationArn": "<association arn>",
        "sourceApiId": "<source api id>",
        "sourceApiArn": "<source api arn>",
        "mergedApiArn": "<merged api arn>",
        "mergedApiId": "<merged api id>",
        "sourceApiAssociationConfig": {
            "mergeType": "MANUAL_MERGE"
        },
        "sourceApiAssociationStatus": "MERGE_FAILED",
        "sourceApiAssociationStatusDetail": "Unable to resolve conflict on object with name title: Merging is not supported for fields with different types."
    }
}

Fusiones manuales

La configuración predeterminada de una API de origen es una fusión manual. Para combinar cualquier cambio que se haya producido en las API de origen desde la última actualización de la API combinada, el propietario de la API de origen puede realizar una combinación manual desde la AWS AppSync consola o mediante la StartSchemaMerge operación disponible en el AWS SDK y la CLI. AWS

Asistencia adicional para las API fusionadas

Configuración de suscripciones

A diferencia de los enfoques basados en enrutadores para la composición de esquemas de GraphQL, las API AWS AppSync combinadas proporcionan soporte integrado para las suscripciones de GraphQL. Todas las operaciones de suscripción definidas en sus API de origen asociadas se fusionarán automáticamente y funcionarán en la API combinada sin modificaciones. Para obtener más información sobre cómo se AWS AppSync admiten las suscripciones a través de una conexión sin servidor WebSockets , consulta los datos. Real-time

Configuración de la observabilidad

AWS AppSync Las API combinadas proporcionan registros, monitorización y métricas integrados a través de Amazon CloudWatch. AWS AppSync también proporciona soporte integrado para el seguimiento de AWS X-Ray.

Configuración de dominios personalizados

AWS AppSync Las API combinadas proporcionan soporte integrado para el uso de dominios personalizados con los puntos Real-time finales y GraphQL de la API fusionada.

Configuración del almacenamiento en caché

AWS AppSync Las API combinadas proporcionan soporte integrado para almacenar en caché, de manera opcional, las respuestas a nivel de and/or resolución a nivel de solicitud, así como la compresión de respuestas. Para obtener más información, consulte Almacenamiento en caché y compresión.

Configuración de API privadas

AWS AppSync Las API combinadas proporcionan compatibilidad integrada para las API privadas, que limitan el acceso a los puntos de enlace y GraphQL de las API fusionadas al tráfico que se origina en los Real-time puntos de enlace de la VPC que puedes configurar. https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html

Configuración de reglas de firewall

AWS AppSync Las API combinadas proporcionan compatibilidad integrada AWS WAF, lo que le permite proteger sus API mediante la definición de reglas de firewall de aplicaciones web.

Configuración de registros de auditoría

AWS AppSync Las API combinadas proporcionan soporte integrado para AWS CloudTrail, lo que le permite configurar y administrar los registros de auditoría.

Limitaciones de las API fusionadas

Tenga en cuenta las siguientes reglas cuando desarrolle API fusionadas:

Consideraciones sobre la combinación de API

Al diseñar e implementar las API combinadas, tenga en cuenta lo siguiente:

La fusión de varias API de origen en un único punto final puede aumentar el tamaño y la complejidad del esquema y las consultas de GraphQL. A medida que tu esquema fusionado crezca, es posible que las consultas tengan que pasar por varios solucionadores para cumplir con una sola solicitud, lo que puede añadir latencia al tiempo total de solicitud. Por ejemplo, una consulta que acceda a campos de varias API de origen puede requerir AWS AppSync ejecutar los solucionadores de cada API de origen de forma secuencial, y cada uno de ellos aumentará el tiempo total de respuesta.

Te recomendamos encarecidamente que pruebes minuciosamente las API combinadas durante el desarrollo y en condiciones de carga realistas para asegurarte de que cumplen los requisitos de tu empresa. Presta especial atención a:

Considere la posibilidad de implementar optimizaciones del rendimiento, como el almacenamiento en caché, la agrupación por lotes de las solicitudes de fuentes de datos y el diseño de sus esquemas de API de origen para minimizar la cantidad de ejecuciones de resolución necesarias para las operaciones comunes.

Creación de API fusionadas

Para crear una API fusionada en la consola