Asociación de un origen de datos en AWS AppSync - AWS AppSync GraphQL
Tipos de orígenes de datosAdición de un origen de datos

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.

Asociación de un origen de datos en AWS AppSync

Los orígenes de datos son recursos de la cuenta de AWS con los que pueden interactuar las API de GraphQL.AWS AppSync admite varios orígenes de datos, como AWS Lambda, Amazon DynamoDB, bases de datos relacionales (Amazon Aurora sin servidor), Amazon OpenSearch Service y puntos de conexión HTTP. Una API de AWS AppSync se puede configurar para interactuar con varios orígenes de datos, lo que permite agregar datos en una sola ubicación. AWS AppSync puede usar los recursos de AWS existentes de su cuenta o aprovisionar tablas de DynamoDB en su nombre a partir de una definición de esquema.

La sección siguiente muestra cómo asociar un origen de datos a la API de GraphQL.

Tipos de orígenes de datos

Ahora que ha creado un esquema en la consola de AWS AppSync y la ha guardado, puede añadir un origen de datos. Al crear una API por primera vez, existe la opción de aprovisionar una tabla de Amazon DynamoDB durante la creación del esquema predefinido. Sin embargo, en esta sección no hablaremos de esa opción. Puede ver un ejemplo de esto en la sección Lanzamiento de un esquema.

Ahora, analizaremos todos los orígenes de datos compatibles con AWS AppSync. Para elegir la solución adecuada para su aplicación se tienen en cuenta numerosos factores. Las siguientes secciones proporcionarán más contexto para cada origen de datos. Para obtener información general sobre los orígenes de datos, consulte Orígenes de datos.

Amazon DynamoDB

Amazon DynamoDB es una de las principales soluciones de almacenamiento de AWS para aplicaciones escalables. El componente principal de DynamoDB es la tabla, que es simplemente una recopilación de datos. Por lo general, las tablas se crean a partir de entidades como Book o Author. La información de las entradas de la tabla se almacena como elementos, que son grupos de campos únicos para cada entrada. Un elemento completo representa una fila o un registro de la base de datos. Por ejemplo, un elemento de una entrada de Book puede incluir title y author junto con sus valores. Cada uno de los campos, como el de title y el de author, se denominan atributos, que son similares a los valores de las columnas en las bases de datos relacionales.

Como puede suponer, las tablas se utilizarán para almacenar datos de su aplicación. AWS AppSync permite enlazar las tablas de DynamoDB a la API de GraphQL para manipular datos. Tomemos este caso de uso del blog Frontend web y móvil. Esta aplicación permite a los usuarios registrarse en una aplicación de redes sociales. Los usuarios pueden unirse a grupos y cargar publicaciones que se difunden a otros usuarios suscritos al grupo. Su aplicación almacena información de usuarios, de publicaciones y de grupos de usuarios en DynamoDB. La API de GraphQL (gestionada por AWS AppSync) interactúa con la tabla de DynamoDB. Cuando un usuario realiza cambios en el sistema que se vaya a reflejar en el frontend, la API de GraphQL los recupera y los difunde a otros usuarios en tiempo real.

AWS Lambda

Lambda es un servicio basado en eventos que crea automáticamente los recursos necesarios para ejecutar código como respuesta a un evento. Lambda utiliza funciones, es decir, instrucciones de grupo que contienen el código, las dependencias y las configuraciones para ejecutar un recurso. Las funciones se ejecutan automáticamente cuando detectan un disparador, es decir, un grupo de actividades que invocan la función. Un disparador puede ser cualquier cosa, por ejemplo una aplicación que realiza una llamada a la API, un servicio de AWS de la cuenta que activa un recurso, etc. Cuando se activen, las funciones procesarán eventos, que son documentos JSON que contienen los datos que se van a modificar.

Lambda es ideal para ejecutar código sin tener que aprovisionar los recursos para ejecutarlo. Tomemos este caso de uso del blog Frontend web y móvil. Este caso de uso es algo parecido al que se muestra en la sección de DynamoDB. En esta aplicación, la API de GraphQL es responsable de definir las operaciones para acciones como la incorporación de publicaciones (mutaciones) y la obtención de esos datos (consultas). Para implementar la funcionalidad de sus operaciones (por ejemplo, getPostsByAuthor ( author: String ! ) : [ Post ] o getPost ( id: String ! ) : Post), utilizan las funciones de Lambda para procesar las solicitudes entrantes. En Opción 2: AWS AppSync con el solucionador de Lambda, utilizan el servicio de AWS AppSync para mantener su esquema y enlazar un origen de datos de Lambda a una de las operaciones. Cuando se llama a la operación, Lambda interactúa con el Amazon RDS proxy para ejecutar la lógica empresarial en la base de datos.

Amazon RDS

Amazon RDS permite crear y configurar rápidamente bases de datos relacionales. En Amazon RDS, creará una instancia de base de datos genérica que servirá como entorno de base de datos aislado en la nube. En esta instancia, utilizará un motor de base de datos, que es de hecho el software de RDBMS (PostgreSQL, MySQL, etc.). El servicio aligera gran parte del trabajo de backend, ya que proporciona escalabilidad mediante el uso de la infraestructura y los servicios de seguridad de AWS, por ejemplo la aplicación de parches y el cifrado, y reduce los costes administrativos de las implementaciones.

Tomemos el mismo caso de uso de la sección Lambda. En Opción 3: AWS AppSync con el solucionador de Amazon RDS, se presenta otra opción que consiste en enlazar la API de GraphQL de AWS AppSync directamente a Amazon RDS. Mediante una API de datos, asocian la base de datos con la API de GraphQL. Un solucionador se adjunta a un campo (normalmente una consulta, una mutación o una suscripción) e implementa las instrucciones SQL necesarias para acceder a la base de datos. Cuando el cliente realiza una solicitud de llamada del campo, el solucionador ejecuta las instrucciones y devuelve la respuesta.

Amazon EventBridge

En EventBridge, creará buses de eventos, que son canalizaciones que reciben eventos de los servicios o de las aplicaciones que adjuntes (el origen de los eventos) y los procesan de conformidad con un conjunto de reglas. Un evento es un cambio de estado de un entorno de ejecución, mientras que una regla es un conjunto de filtros para eventos. Una regla sigue un patrón de eventos o los metadatos del cambio de estado de un evento (ID, región, número de cuenta, ARN, etc.). Cuando un evento coincida con el patrón de eventos, EventBridge enviará el evento por la canalización al servicio de destino (el destino) y activará la acción especificada en la regla.

EventBridge es útil para direccionar las operaciones que cambian de estado a algún otro servicio. Tomemos este caso de uso del blog Frontend web y móvil. El ejemplo muestra una solución de comercio electrónico en la que varios equipos mantienen servicios diversos. Uno de estos servicios proporciona al cliente actualizaciones de los pedidos en cada paso de la entrega (pedido realizado, en curso, enviado, entregado, etc.) en el frontend. Sin embargo, el equipo de frontend que gestiona este servicio no tiene acceso directo a los datos del sistema de pedidos, ya que los mantiene un equipo de backend independiente. El sistema de pedidos del equipo de backend también se describe como una caja negra, por lo que es difícil obtener información sobre la forma en que estructuran sus datos. Sin embargo, el equipo de backend creó un sistema que publicaba los datos de los pedidos a través de un bus de eventos gestionado por EventBridge. Para acceder a los datos procedentes del bus de eventos y dirigirlos al frontend, el equipo de frontend ha creado un nuevo objetivo que apunta a su API de GraphQL ubicada en AWS AppSync. También han creado una regla para enviar solo los datos relevantes para la actualización del pedido. Cuando se realiza una actualización, los datos del bus de eventos se envían a la API de GraphQL. El esquema de la API procesa los datos y, a continuación, los pasa al frontend.

Orígenes de datos none

Si no tiene pensado utilizar un origen de datos, puede configurarlo como none. Un origen de datos none, aunque se siga considerando explícitamente un origen de datos, no es un medio de almacenamiento. Por lo general, un solucionador invocará uno o más orígenes de datos en algún momento para procesar la solicitud. Sin embargo, hay situaciones en las que tal vez no sea necesario manipular un origen de datos. Si se configura el origen de datos en none, se ejecutará la solicitud, se omitirá el paso de invocación de datos y, a continuación, se ejecutará la respuesta.

Tomemos el mismo caso de uso de la sección EventBridge. En el esquema, la mutación procesa la actualización del estado y, a continuación, la envía a los suscriptores. Al recordar cómo funcionan los solucionadores, normalmente hay al menos una invocación al origen de datos. Sin embargo, en este escenario, el bus de eventos ya ha enviado los datos automáticamente. Esto significa que no es necesario que la mutación realice una invocación al origen de datos, sino que el estado del pedido puede gestionarse simplemente de forma local. La mutación se establece en none, que actúa como un valor de transferencia sin invocar el origen de datos. A continuación, se rellena el esquema con los datos, que se envían a los suscriptores.

OpenSearch

Amazon OpenSearch Service es un conjunto de herramientas para implementar la búsqueda de texto completo, la visualización de datos y el registro. Puede utilizar este servicio para consultar los datos estructurados que ha cargado.

En este servicio, creará instancias de OpenSearch. Estos se denominan nodos. En un nodo, agregará al menos un índice. Conceptualmente, los índices se parece un poco a las tablas de bases de datos relacionales. (Sin embargo, OpenSearch no es compatible con ACID, por lo que no debe usarse de esa manera). Rellenará el índice con los datos que cargue al servicio OpenSearch. Cuando se carguen los datos, se indexarán en una o más particiones que existan en el índice. Una partición es como una subdivisión del índice que contiene algunos de sus datos y se puede consultar por separado de otras particiones. Una vez cargados, los datos se estructurarán como archivos JSON denominados documentos. A continuación, puede consultar los datos del documento en el nodo.

Puntos de conexión HTTP

Puede usar puntos de conexión HTTP como orígenes de datos. AWS AppSync puede enviar solicitudes a los puntos de conexión con la información relevante, como los parámetros y la carga. La respuesta HTTP estará expuesta al solucionador, que devolverá la respuesta final cuando finalice sus operaciones.

Adición de un origen de datos

Si ha creado un origen de datos, puede enlazarlo al servicio de AWS AppSync y, más específicamente, a la API.

Console

  1. Inicie sesión en la AWS Management Console y abra la consola de AppSync.

    1. En el panel, elija su API.

    2. En la barra lateral, seleccione Origen de datos.

  2. Elija Crear origen de datos.

    1. Asigne un nombre al origen de datos. También puede asignarle una descripción, pero eso es opcional.

    2. Elija el tipo de origen de datos.

    3. Para DynamoDB, elija su región y, a continuación, la tabla dentro de la región. Para dictar las reglas de interacción con su tabla, elija crear un nuevo rol de tabla genérico o importe un rol existente para la tabla. Puede habilitar el control de versiones, que permite crear automáticamente versiones de los datos para cada solicitud cuando hay varios clientes intentando actualizar los datos al mismo tiempo. El control de versiones se utiliza para conservar y mantener múltiples variantes de datos con el fin de detectar y resolver conflictos. También puede habilitar la generación automática de esquemas, que toma el origen de datos y genera algunas de las operaciones CRUD, List y Query necesarias para acceder a ella en el esquema.

      En el caso de OpenSearch, tendrá que elegir su región y, a continuación, el dominio (clúster) de la región. Para dictar las reglas de interacción con su dominio, elija crear un nuevo rol de tabla genérico o importe un rol existente para la tabla.

      Para Lambda, elija su región y, a continuación, el ARN de la función de Lambda de la región. Para dictar las reglas de interacción con su función de Lambda, elija crear un nuevo rol de tabla genérico o importe un rol existente para la tabla.

      Para HTTP, introduzca su punto de conexión HTTP.

      Para EventBridge, elija su región y, a continuación, el bus de eventos de la región. Para dictar las reglas de interacción con su bus de eventos, elija crear un nuevo rol de tabla genérico o importe un rol existente para la tabla.

      Para RDS, elija su región y, a continuación, el almacén secreto (nombre de usuario y contraseña), el nombre de la base de datos y el esquema.

      Para none, añada un origen de datos sin un origen de datos real. Esto sirve para gestionar los solucionadores de forma local y no a través de un origen de datos real.

      nota

      Si importa roles existentes, estos necesitan una política de confianza. Para obtener más información, consulte la política de confianza de IAM.

  3. Seleccione Crear.

    nota

    Como alternativa, si va a crear un origen de datos de DynamoDB, puede ir a la página Esquema de la consola, elegir Crear recursos en la parte superior de la página y, a continuación, rellenar un modelo predefinido para convertirlo en una tabla. En esta opción, rellenará o importará el tipo base, configurará los datos básicos de la tabla, incluida la clave de partición, y revisará los cambios del esquema.

CLI

  • Cree su origen de datos ejecutando el comando create-data-source.

    Para este comando en particular, deberá introducir varios parámetros:

    1. El api-id de su API.

    2. El name de su tabla.

    3. El type de su origen de datos. Según el tipo de origen de datos que elija, es posible que deba introducir una etiqueta service-role-arn y -config.

    Un comando de ejemplo puede tener este aspecto:

     aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name data_source_name --type data_source_type --service-role-arn arn:aws:iam::107289374856:role/role_name --[data_source_type]-config {params}
CDK
sugerencia

Antes de usar el CDK, le recomendamos que consulte la documentación oficial de este, junto con la referencia del CDK de AWS AppSync.

Los pasos que se indican a continuación solo mostrarán un ejemplo general del fragmento de código utilizado para añadir un recurso concreto. No se pretende que esta sea una solución funcional en su código de producción. También, se presupone que ya tiene una aplicación en funcionamiento.

Para añadir un origen de datos concreto, añada el constructo a su archivo de pila. Puede encontrar una lista de los tipos de orígenes de datos aquí:

  1. En general, puede que tenga que añadir la directiva de importación al servicio que utilice. Por ejemplo, puede seguir estas formas:

    import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'

    Por ejemplo, así es cómo se importan los servicios AWS AppSync y DynamoDB:

    import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';

  2. Algunos servicios, como RDS, requieren una configuración adicional en el archivo de pila antes de crear el origen de datos (por ejemplo, la creación de VPC, las funciones y las credenciales de acceso). Consulte los ejemplos de las páginas de CDK correspondientes para obtener más información.

  3. Para la mayoría de los orígenes de datos, especialmente para los servicios de AWS, creará una nueva instancia del origen de datos en su archivo de pila. Normalmente, será como esta:

    const add_data_source_func = new service_scope.resource_name(scope: Construct, id: string, props: data_source_props);

    Por ejemplo, a continuación se muestra un ejemplo de tabla de Amazon DynamoDB:

    const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  partitionKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  sortKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  tableClass: dynamodb.TableClass.STANDARD,
});
    nota

    La mayoría de los orígenes de datos tendrán al menos un accesorio obligatorio (se indicará sin el símbolo ?). Consulte la documentación del CDK para ver qué accesorios se necesitan.

  4. A continuación, debe enlazar el origen de datos a la API de GraphQL. El método recomendado es añadirlo al crear una función para su solucionador de canalizaciones. Por ejemplo, el fragmento de código siguiente es una función que analiza todos los elementos de una tabla de DynamoDB:

    const add_func = new appsync.AppsyncFunction(this, 'func_ID', {
  name: 'func_name_in_console',
  add_api,
  dataSource: add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table),
  code: appsync.Code.fromInline(`
      export function request(ctx) {
        return { operation: 'Scan' };
      }

      export function response(ctx) {
        return ctx.result.items;
      }
  `),
  runtime: appsync.FunctionRuntime.JS_1_0_0,
});

    En los accesorios de dataSource, puede llamar a la API de GraphQL (add_api) y usar uno de sus métodos integrados (addDynamoDbDataSource) para realizar la asociación entre la tabla y la API de GraphQL. Los argumentos son el nombre de este enlace que existirá en la consola AWS AppSync (data_source_name_in_console en este ejemplo) y el método de tabla (add_ddb_table). Encontrará más información sobre este tema en la sección siguiente cuando empiece a crear solucionadores.

    Existen métodos alternativos para enlazar un origen de datos. Técnicamente, podría añadir api a la lista de accesorios de la función de tabla. Por ejemplo, este es el fragmento de código del paso 3, pero con un accesorio api que contiene una API de GraphQL:

    const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {

 ...

  api: add_api
});

    Como alternativa, puede llamar al constructo GraphqlApi por separado:

    const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  ...
});

const link_data_source = add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table);

    Recomendamos crear la asociación únicamente en los accesorios de la función. De lo contrario, tendrá que enlazar la función de solucionador al origen de datos manualmente en la consola AWS AppSync (si desea seguir utilizando el valor de consola data_source_name_in_console) o crear una asociación independiente en la función con otro nombre como data_source_name_in_console_2. Esto se debe a las limitaciones en la forma en que los accesorios procesan la información.

    nota

    Deberá volver a implementar la aplicación para ver los cambios.

Política de confianza de IAM

Si utiliza un rol de IAM ya existente para el origen de datos, deberá conceder a ese rol los permisos adecuados para llevar a cabo operaciones en su recurso de AWS, por ejemplo PutItem en una tabla de Amazon DynamoDB. También tiene que modificar la política de confianza de ese rol para permitir que AWS AppSync la use en el acceso de recursos tal como se muestra en el ejemplo de política siguiente:

{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
            "Service": "appsync.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
}

También puede añadir condiciones a su política de confianza para limitar el acceso al origen de datos según lo desee. Actualmente, las claves SourceArn y SourceAccount se pueden utilizar en estas condiciones. Por ejemplo, la política siguiente limita el acceso a su origen de datos a la cuenta 123456789012:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}

Como alternativa, puede limitar el acceso a un origen de datos a una API específica, por ejemplo abcdefghijklmnopq, mediante la política siguiente:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-west-2:123456789012:apis/abcdefghijklmnopq"
        }
      }
    }
  ]
}

Puede limitar el acceso a todas las API de AWS AppSync desde una región específica, por ejemplo us-east-1, mediante la política siguiente:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-east-1:123456789012:apis/*"
        }
      }
    }
  ]
}

En la sección siguiente (Configuración de los solucionadores), añadiremos nuestra lógica empresarial de solucionador y la asociaremos a los campos de nuestro esquema para procesar los datos de nuestro origen de datos.

Para obtener más información sobre la configuración de la política de roles, consulte Modificación de un rol en la Guía del usuario de IAM.

Para obtener más información sobre el acceso entre cuentas a los solucionadores de AWS Lambda de AWSAppSync, consulte Creación de solucionadores de AWS Lambda entre cuentas para AWS AppSync.