Adjuntar una fuente de datos en AWS AppSync - AWS AppSync
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.

Adjuntar una fuente de datos en AWS AppSync

Las fuentes de datos son recursos de tu AWS cuenta con los que GraphQL APIs puede interactuar. AWS AppSync admite múltiples fuentes de datos AWS Lambda, como Amazon DynamoDB, bases de datos relacionales (Amazon Aurora Serverless), Amazon OpenSearch Service y puntos de conexión. HTTP An se AWS AppSync API puede configurar para interactuar con varias fuentes de datos, lo que le permite agregar datos en una sola ubicación. AWS AppSync puede utilizar AWS los recursos existentes de su cuenta o aprovisionar tablas de DynamoDB en su nombre a partir de una definición de esquema.

La siguiente sección le mostrará cómo adjuntar una fuente de datos a su GraphQLAPI.

Tipos de orígenes de datos

Ahora que has creado un esquema en la AWS AppSync consola, puedes adjuntarle una fuente de datos. Al crear una por primera vezAPI, 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.

En su lugar, analizaremos todas las fuentes AWS AppSync de datos compatibles. 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 AWS de almacenamiento 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 adivinar, las tablas se utilizarán para almacenar los datos de su aplicación. AWS AppSync le permite conectar las tablas de DynamoDB a su GraphQL API para manipular los 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. El GraphQL API (gestionado por AWS AppSync) interactúa con la tabla de DynamoDB. Cuando un usuario realiza un cambio en el sistema que se reflejará en la interfaz, API GraphQL recupera estos cambios y los transmite 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 desencadenante puede ser algo parecido a que una aplicación haga una API llamada, que un AWS servicio de tu cuenta active un recurso, etc. Cuando se activan, las funciones procesarán los eventos, que son JSON documentos 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, GraphQL API es responsable de definir las operaciones para cosas como añadir publicaciones (mutaciones) y obtener 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 la opción 2: AWS AppSync con el solucionador Lambda, utilizan el AWS AppSync servicio para mantener su esquema y vincular una fuente de datos Lambda a una de las operaciones. Cuando se llama a la operación, Lambda interactúa con el RDS proxy de Amazon para ejecutar la lógica empresarial en la base de datos.

Amazon RDS

Amazon RDS le permite crear y configurar bases de datos relacionales rápidamente. En AmazonRDS, crearás una instancia de base de datos genérica que servirá como entorno de base de datos aislado en la nube. En este caso, utilizará un motor de base de datos, que es el RDBMS software real (PostgreSQL, MySQL, etc.). El servicio reduce gran parte del trabajo de back-end, ya que proporciona escalabilidad mediante AWS la infraestructura y los servicios de seguridad, como 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 la opción 3: AWS AppSync con Amazon RDS Resolver, se presenta otra opción que consiste API en vincular GraphQL directamente a AWS AppSync AmazonRDS. Usando un dato API, asocian la base de datos con GraphQLAPI. Se adjunta un solucionador a un campo (normalmente una consulta, mutación o suscripción) e implementa SQL las instrucciones 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ás buses de eventos, que son canalizaciones que reciben eventos de los servicios o aplicaciones que adjuntas (la fuente de eventos) y los procesarán en función de 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 metadatos del cambio de estado de un evento (identificador, región, ARN número de cuenta, etc.). Cuando un evento coincide con el patrón de eventos, EventBridge lo envía de forma continua al servicio de destino (objetivo) y desencadena la acción especificada en la regla.

EventBridge es adecuado para enrutar 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 front-end, el equipo de front-end creó un nuevo objetivo que apuntaba a su API GraphQL instalado. 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 GraphQLAPI. El esquema del archivo API procesa los datos y, a continuación, los pasa al front-end.

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 EventBridge sección. 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ás 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 ACID compatible, por lo que no debe usarse de esa manera). Rellenarás tu índice con los datos que subas al OpenSearch servicio. 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 JSON archivos denominados documentos. A continuación, puede consultar los datos del documento en el nodo.

HTTPpuntos finales

Puede utilizar los HTTP puntos finales como fuentes de datos. AWS AppSync puede enviar solicitudes a los puntos finales con la información relevante, como los parámetros y la carga útil. La HTTP respuesta se mostrará al solucionador, que devolverá la respuesta final una vez que finalice su (s) operación (es).

Adición de un origen de datos

Si ha creado una fuente de datos, puede vincularla al AWS AppSync servicio y, más específicamente, alAPI.

Console

  1. Inicie sesión en la AppSyncconsola AWS Management Console y ábrala.

    1. Elige la tuya API en el panel de control.

    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 la fuente de datos y genera algunas de las CRUD Query operaciones necesarias para acceder a ella en su esquema. List

      Para OpenSearch ello, 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.

      En el caso de Lambda, tendrá que elegir su región y, a continuación, la ARN de la función 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 ello, tendrá que introducir su HTTP punto final.

      Para EventBridge ello, tendrás que elegir tu región y, a continuación, el autobús del evento en 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 elloRDS, tendrás que elegir tu 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, consulta la política de IAM confianza.

  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 tusAPI.

    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 utilizar elCDK, le recomendamos que revise CDK la documentación oficial junto con AWS AppSync su CDKreferencia.

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 como puede importar 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 RDS requieren una configuración adicional en el archivo de pila antes de crear la fuente de datos (por ejemplo, la VPC creación, las funciones y las credenciales de acceso). Consulte los ejemplos de las CDK páginas correspondientes para obtener más información.

  3. Para la mayoría de las fuentes de datos, especialmente para AWS los servicios, crearás una nueva instancia de la fuente de datos en el 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 ?). Consulta la CDK documentación para ver qué accesorios son necesarios.

  4. A continuación, debe vincular la fuente de datos a GraphQLAPI. 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 dataSource accesorios, puedes llamar a API GraphQL add_api () y usar uno de sus métodos integrados addDynamoDbDataSource () para hacer la asociación entre la tabla y GraphQL. API Los argumentos son el nombre de este enlace que existirá en la AWS AppSync consola (data_source_name_in_consoleen 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 del paso 3, pero con un api accesorio que contiene un GraphQL: API

    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ás que vincular tu función de resolución a la fuente de datos manualmente en la AWS AppSync consola (si quieres seguir usando el valor de la consoladata_source_name_in_console) o crear una asociación independiente en la función con otro nombre, por ejemplo. 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.

IAMpolítica de confianza

Si utiliza una IAM función existente para la fuente de datos, debe conceder a esa función los permisos adecuados para realizar operaciones en el AWS recurso, por ejemplo, PutItem en una tabla de Amazon DynamoDB. También debe modificar la política de confianza de ese rol para poder usarlo para el acceso AWS AppSync a los recursos, como se muestra en el siguiente ejemplo de política:

{
    "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 una fuente de datos específicaAPI, por ejemploabcdefghijklmnopq, mediante la siguiente política:

{
  "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 todos los AWS AppSync APIs usuarios de una región específica, por ejemplous-east-1, mediante la siguiente política:

{
  "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 IAM usuario.

Para obtener más información sobre el acceso multicuenta a los AWS Lambda solucionadores AWS AppSync, consulte Creación de resolutores multicuentas AWS Lambda para. AWS AppSync