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.
# Estructuración de una API de GraphQL (en blanco o importada) APIs
Para crear su API de GraphQL a partir de una plantilla en blanco, antes sería útil revisar los conceptos relacionados con GraphQL. Hay tres componentes fundamentales de una API de GraphQL:
1. El **esquema** es el archivo que contiene la forma y la definición de los datos. Cuando un cliente realice una solicitud a su servicio GraphQL, los datos devueltos seguirán la especificación del esquema. Para obtener más información, consulte [Esquemas de GraphQL](schema-components.md#aws-appsync-schema-components).
1. El **origen de datos** se adjunta a su esquema. Cuando se realiza una solicitud, aquí es donde se recuperan y modifican los datos. Para obtener más información, consulte [Orígenes de datos](data-source-components.md#aws-appsync-data-source-components).
1. El **solucionador** se encuentra entre el esquema y el origen de datos. Cuando se realiza una solicitud, el solucionador realiza la operación con los datos del origen y, a continuación, devuelve el resultado como respuesta. Para obtener más información, consulte [Solucionadores](resolver-components.md#aws-appsync-resolver-components).
![\[GraphQL API architecture showing schema, resolvers, and data sources connected via AppSync.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/appsync-architecture-graphql-api.png)
AWS AppSync la gestiona APIs al permitirle crear, editar y almacenar el código para sus esquemas y resoluciones. Los orígenes de datos procederán de repositorios externos, como bases de datos, tablas de DynamoDB y funciones de Lambda. Si utilizas un AWS servicio para almacenar tus datos o planeas hacerlo, AWS AppSync ofrece una experiencia prácticamente perfecta a la hora de asociar los datos de tus AWS cuentas a tu GraphQL. APIs
En la siguiente sección, aprenderás a crear cada uno de estos componentes mediante el servicio. AWS AppSync
**Topics**
+ [Diseño de esquemas de GraphQL](designing-your-schema.md)
+ [Asociación de un origen de datos](attaching-a-data-source.md)
+ [Configuración de solucionadores de AWS AppSync](resolver-config-overview.md)
+ [Utilizándolo APIs con el CDK](using-your-api.md)
# Diseño de esquemas de GraphQL
El esquema GraphQL es la base de cualquier implementación de servidor GraphQL. Cada API de GraphQL se define mediante un **solo** esquema que contiene tipos y campos que describen cómo se rellenarán los datos de las solicitudes. Los datos que fluyen a través de la API y las operaciones realizadas deben validarse con respecto al esquema.
En general, el [sistema de tipos de GraphQL](https://graphql.org/learn/schema/#type-system) describe las funcionalidades de un servidor GraphQL y se utiliza para determinar si una consulta es válida. El sistema de tipos de un servidor suele denominarse esquema de ese servidor y puede constar de diferentes tipos de objetos, tipos escalares, tipos de entradas, etc. GraphQL es declarativo y tiene establecimiento inflexible de tipos, lo que significa que los tipos estarán bien definidos en tiempo de ejecución y solo devolverán lo que se haya especificado.
AWS AppSync permite definir y configurar esquemas de GraphQL. En la siguiente sección se describe cómo crear esquemas de GraphQL desde cero utilizando AWS AppSync los servicios.
## Estructuración de un esquema de GraphQL
**sugerencia**
Recomendamos consultar la sección [Esquemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html) antes de continuar.
GraphQL es una poderosa herramienta para implementar servicios de API. Según el [sitio web de GraphQL](https://graphql.org/), GraphQL es lo siguiente:
«*GraphQL es un lenguaje de consulta APIs y un entorno de ejecución para completar esas consultas con los datos existentes. GraphQL proporciona una descripción completa y comprensible de los datos de tu API, da a los clientes la posibilidad de pedir exactamente lo que necesitan y nada más, facilita la evolución APIs con el tiempo y habilita potentes herramientas para desarrolladores.* »
Esta sección cubre la primera parte de la implementación de GraphQL, el esquema. Siguiendo la cita anterior, un esquema cumple la función de “proporcionar una descripción completa y comprensible de los datos de su API”. En otras palabras, un esquema GraphQL es una representación textual de los datos, las operaciones y las relaciones entre ellos de su servicio. El esquema se considera el punto de entrada principal para la implementación del servicio GraphQL. Como era de esperar, suele ser una de las primeras cosas que hace en su proyecto. Recomendamos consultar la sección [Esquemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html) antes de continuar.
Para citar la sección [Esquemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html), los esquemas de GraphQL se escriben en el *lenguaje de definición de esquema* (SDL). SDL está compuesto por tipos y campos con una estructura establecida:
+ **Tipos**: los tipos son la forma en que GraphQL define la forma y el comportamiento de los datos. GraphQL admite una multitud de tipos que se explicarán más adelante en esta sección. Cada tipo que se defina en su esquema tendrá su propio ámbito. Dentro del ámbito habrá uno o más campos que pueden contener un valor o una lógica que se utilice en el servicio GraphQL. Los tipos cumplen muchos roles diferentes, siendo las más comunes los objetos o los escalares (tipos de valores primitivos).
+ **Campos**: los campos existen dentro del ámbito de un tipo y contienen el valor que se solicita al servicio GraphQL. Se parecen mucho a las variables de otros lenguajes de programación. La forma de los datos que defina en sus campos determinará cómo se estructuran los datos en una request/response operación. Esto permite a los desarrolladores predecir lo que se va a devolver sin saber cómo se implementa el backend del servicio.
Los esquemas más simples contendrán tres categorías de datos diferentes:
1. **Raíces del esquema**: las raíces definen los puntos de entrada de su esquema. Señala los campos que realizarán alguna operación con los datos, como añadir, eliminar o modificar algo.
1. **Tipos**: son tipos básicos que se utilizan para representar la forma de los datos. Casi se puede pensar en ellos como objetos o representaciones abstractas de algo con características definidas. Por ejemplo, podría crear un objeto `Person` que represente a una persona en una base de datos. Las características de cada persona se definirán dentro de `Person` como campos. Pueden ser cualquier cosa, como el nombre, la edad, el trabajo, la dirección, etc. de la persona.
1. **Tipos de objetos especiales**: son los tipos que definen el comportamiento de las operaciones del esquema. Cada tipo de objeto especial se define una vez por cada esquema. Primero se colocan en la raíz del esquema y, a continuación, se definen en el cuerpo del esquema. Cada campo de un tipo de objeto especial define una sola operación que debe implementar el solucionador.
Para poner esto en perspectiva, imagine que está creando un servicio que almacena autores y los libros que han escrito. Cada autor tiene un nombre y una serie de libros que han escrito. Cada libro tiene un nombre y una lista de autores asociados. También queremos poder añadir o recuperar libros y autores. Una representación UML simple de esta relación puede tener este aspecto:
![\[UML diagram showing Author and Book classes with attributes and methods, linked by association.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/GraphQL-UML-1.png)
En GraphQL, las entidades `Author` y `Book` representan dos tipos de objetos diferentes en el esquema:
```
type Author {
}
type Book {
}
```
`Author` contiene `authorName` y `Books`, mientras que `Book` contiene `bookName` y `Authors`. Estos se pueden representar como los campos incluidos en el ámbito de sus tipos:
```
type Author {
authorName: String
Books: [Book]
}
type Book {
bookName: String
Authors: [Author]
}
```
Como puede ver, las representaciones de tipos se parecen mucho al diagrama. Sin embargo, los métodos son algo más complicados. Se colocarán como campo en uno de algunos tipos de objetos especiales. La categorización de los objetos especiales depende de su comportamiento. GraphQL contiene tres tipos de objetos especiales fundamentales: consultas, mutaciones y suscripciones. Para obtener más información sobre los objetos, consulte [Objetos especiales](https://docs.aws.amazon.com//appsync/latest/devguide/graphql-types.html#special-object-components).
Como tanto `getAuthor` como `getBook` solicitan datos, se colocarán en un tipo de objeto especial de `Query`:
```
type Author {
authorName: String
Books: [Book]
}
type Book {
bookName: String
Authors: [Author]
}
type Query {
getAuthor(authorName: String): Author
getBook(bookName: String): Book
}
```
Las operaciones están vinculadas a la consulta, que a su vez está vinculada al esquema. Cuando se añade una raíz de esquema, se define el tipo de objeto especial (en este caso, `Query`) como uno de los puntos de entrada. Esto se puede hacer con la palabra clave `schema`:
```
schema {
query: Query
}
type Author {
authorName: String
Books: [Book]
}
type Book {
bookName: String
Authors: [Author]
}
type Query {
getAuthor(authorName: String): Author
getBook(bookName: String): Book
}
```
Si nos fijamos en los dos últimos métodos, `addAuthor` y `addBook` añaden datos a la base de datos, por lo que se definirán en un tipo de objeto `Mutation` especial. Sin embargo, por la página [Tipos](https://docs.aws.amazon.com/appsync/latest/devguide/graphql-types.html#input-components), también sabemos que no se permiten entradas que hagan referencia directamente a objetos porque son estrictamente tipos de salida. En este caso, no podemos usar `Author` ni `Book`, por lo que necesitamos crear un tipo de entrada con los mismos campos. En este ejemplo, añadimos `AuthorInput` y`BookInput`, que aceptan los mismos campos de sus tipos correspondientes. A continuación, creamos nuestra mutación usando las entradas como parámetros:
```
schema {
query: Query
mutation: Mutation
}
type Author {
authorName: String
Books: [Book]
}
input AuthorInput {
authorName: String
Books: [BookInput]
}
type Book {
bookName: String
Authors: [Author]
}
input BookInput {
bookName: String
Authors: [AuthorInput]
}
type Query {
getAuthor(authorName: String): Author
getBook(bookName: String): Book
}
type Mutation {
addAuthor(input: [BookInput]): Author
addBook(input: [AuthorInput]): Book
}
```
Repasemos lo que acabamos de hacer:
1. Hemos creado un esquema con los tipos `Book` y `Author` para representar nuestras entidades.
1. Hemos añadido los campos que contienen las características de nuestras entidades.
1. Hemos añadido una consulta para recuperar esta información de la base de datos.
1. Hemos añadido una mutación para manipular los datos de la base de datos.
1. Hemos añadido tipos de entrada para reemplazar los parámetros de nuestro objeto en la mutación y cumplir con las reglas de GraphQL.
1. Hemos añadido la consulta y la mutación a nuestro esquema de raíz para que la implementación de GraphQL entienda la ubicación del tipo de raíz.
Como puede ver, el proceso de creación de un esquema requiere muchos conceptos del modelado de datos (especialmente del modelado de bases de datos) en general. Puede considerarse que el esquema se ajusta a la forma de los datos de la fuente. También sirve como modelo que el solucionador implementará. En las siguientes secciones, aprenderá a crear un esquema utilizando diversas herramientas y servicios AWS respaldados.
**nota**
Los ejemplos de las secciones siguientes no están pensados para ejecutarse en una aplicación real. Con ellos solo se pretende mostrar los comandos para que pueda crear sus propias aplicaciones.
## Creación de esquemas
El esquema estará en un archivo llamado`schema.graphql`. AWS AppSync permite a los usuarios crear nuevos esquemas para su APIs GraphQL utilizando varios métodos. En este ejemplo, crearemos una API en blanco junto con un esquema en blanco.
------
#### [ Console ]
1. [Inicia sesión en la consola Consola de administración de AWS y ábrelaAppSync.](https://console.aws.amazon.com/appsync/)
1. En el **Panel**, elija **Crear API**.
1. **En **Opciones de API**, selecciona **GraphQL APIs**, **Diseña desde cero** y, a continuación, Siguiente.**
1. En **Nombre de la API**, cambie el nombre previamente cumplimentado por el que su aplicación necesite.
1. Para obtener **los detalles de contacto**, puede introducir un punto de contacto para identificar al administrador de la API. Se trata de un campo opcional.
1. En **Configuración de API privada**, puede habilitar las características de API privadas. Solo se puede acceder a una API privada desde un punto de conexión de VPC (VPCE) configurado. Para obtener más información, consulta [Privado APIs](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html).
No le recomendamos habilitar esta característica para este ejemplo. Seleccione **Siguiente** después de revisar sus entradas.
1. En **Crear un tipo de GraphQL**, puede elegir crear una tabla de DynamoDB para utilizarla como origen de datos u omitir este paso y hacerlo más adelante.
Para este ejemplo, elija **Crear recursos de GraphQL más adelante**. Crearemos un recurso en una sección aparte.
1. Revise la información indicada y, a continuación, seleccione **Crear API**.
1. Estará en el panel de control de tu API específica. Lo notará porque el nombre de la API aparecerá en la parte superior del panel de control. **Si este no es el caso, puedes seleccionarla **APIs**en la **barra lateral** y, a continuación, elegir tu API en el APIs panel de control.**
1. En la **barra lateral** situada debajo del nombre de la API, seleccione **Esquema**.
1. En el **Editor de esquemas**, puede configurar su archivo `schema.graphql`. Puede estar vacío o lleno de tipos generados a partir de un modelo. A la derecha, tiene la sección **Solucionadores** para asociar solucionadores a los campos del esquema. En esta sección no nos fijaremos en los solucionadores.
------
#### [ CLI ]
**nota**
Cuando utilice la CLI, asegúrese de tener los permisos correctos para acceder y crear recursos en el servicio. Es posible que desee establecer políticas de [privilegios mínimos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) para los usuarios que no sean administradores y que necesiten acceder al servicio. Para obtener más información sobre AWS AppSync las políticas, consulte [Administración de identidad y acceso](https://docs.aws.amazon.com//appsync/latest/devguide/security-iam.html) para. AWS AppSync
Además, le recomendamos leer primero la versión de consola si aún no lo ha hecho.
1. Si aún no lo ha hecho, [instale](https://docs.aws.amazon.com//cli/latest/userguide/cli-chap-getting-started.html) la CLI de AWS y añadas su [configuración](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-quickstart.html).
1. Cree un objeto de API de GraphQL ejecutando el comando [https://docs.aws.amazon.com/cli/latest/reference/appsync/create-graphql-api.html](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-graphql-api.html).
Deberá escribir dos parámetros para este comando concreto:
1. El `name` de su API.
1. El `authentication-type` o el tipo de credenciales utilizado para acceder a la API (IAM, OIDC, etc.).
**nota**
Otros parámetros, como `Region`, deben configurarse pero normalmente se utilizarán de forma predeterminada en los valores de configuración de la CLI.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-graphql-api --name testAPI123 --authentication-type API_KEY
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"graphqlApi": {
"xrayEnabled": false,
"name": "testAPI123",
"authenticationType": "API_KEY",
"tags": {},
"apiId": "abcdefghijklmnopqrstuvwxyz",
"uris": {
"GRAPHQL": "https://zyxwvutsrqponmlkjihgfedcba.appsync-api.us-west-2.amazonaws.com/graphql",
"REALTIME": "wss://zyxwvutsrqponmlkjihgfedcba.appsync-realtime-api.us-west-2.amazonaws.com/graphql"
},
"arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz"
}
}
```
1.
**nota**
Se trata de un comando opcional que toma un esquema existente y lo carga en el servicio de AWS AppSync mediante un blob de base 64. No utilizaremos este comando para este ejemplo.
Ejecute el comando [https://docs.aws.amazon.com/cli/latest/reference/appsync/start-schema-creation.html](https://docs.aws.amazon.com/cli/latest/reference/appsync/start-schema-creation.html).
Deberá escribir dos parámetros para este comando concreto:
1. Su `api-id` del paso anterior.
1. La `definition` del esquema es un blob binario codificado en base 64.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync start-schema-creation --api-id abcdefghijklmnopqrstuvwxyz --definition "aa1111aa-123b-2bb2-c321-12hgg76cc33v"
```
Se devolverá un resultado:
```
{
"status": "PROCESSING"
}
```
Este comando no devolverá el resultado final después del procesamiento. Para ver el resultado, debe usar un comando diferente, [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/get-schema-creation-status.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/get-schema-creation-status.html). Tenga en cuenta que estos dos comandos son asíncronos, por lo que puede comprobar el estado de la salida incluso mientras se crea el esquema.
------
#### [ CDK ]
**sugerencia**
[Antes de usar la CDK, te recomendamos que consultes la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/home.html) de la CDK junto con AWS AppSync su referencia.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
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.
1. El punto de partida del CDK es ligeramente diferente. Lo ideal es que el archivo `schema.graphql` ya esté creado. Solo necesita crear un nuevo archivo con la extensión de archivo `.graphql`. Puede ser un archivo vacío.
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'
```
Para añadir una API de GraphQL, tu archivo de pila debe importar el AWS AppSync servicio:
```
import * as appsync from 'aws-cdk-lib/aws-appsync';
```
**nota**
Esto significa que vamos a importar todo el servicio con la palabra clave `appsync`. Para usar esto en tu aplicación, tus AWS AppSync construcciones usarán el formato. `appsync.construct_name` Por ejemplo, si quisiéramos crear una API de GraphQL, diríamos `new appsync.GraphqlApi(args_go_here)`. En el siguiente paso se describe esto.
1. La API de GraphQL más básica incluirá un `name` para la API y la ruta de `schema`.
```
const add_api = new appsync.GraphqlApi(this, 'API_ID', {
name: 'name_of_API_in_console',
schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema_name.graphql')),
});
```
**nota**
Repasemos lo que hace este fragmento de código. Dentro del ámbito de `api`, creamos una nueva API de GraphQL llamando a `appsync.GraphqlApi(scope: Construct, id: string, props: GraphqlApiProps)`. El alcance es `this`, que hace referencia al objeto actual. El id es*API\$1ID*, que será el nombre del recurso de tu API de GraphQL CloudFormation cuando se cree. `GraphqlApiProps` contiene el `name` de la API de GraphQL y el `schema`. `schema`Generará un esquema (`SchemaFile.fromAsset`) buscando el `.graphql` archivo (`__dirname`) en la ruta absoluta (*schema\$1name.graphql*). En un escenario real, es probable que su archivo de esquema esté dentro de la aplicación del CDK.
Para usar los cambios realizados en la API de GraphQL, deberá volver a implementar la aplicación.
------
## Adición de tipos a los esquemas
Ahora que ha añadido su esquema, puede empezar a agregar los tipos tanto de entrada como de salida. Tenga en cuenta que los tipos que aparecen aquí no deben usarse en código real; son solo ejemplos que le ayudarán a entender el proceso.
En primer lugar, crearemos un tipo de objeto. En el código real, no es necesario empezar con estos tipos. Puede crear cualquier tipo que desee en cualquier momento siempre que siga las reglas y la sintaxis de GraphQL.
**nota**
Las siguientes secciones usarán el **editor de esquemas**, así que manténgalo abierto.
------
#### [ Console ]
+ Puede crear un tipo de objeto utilizando la palabra clave `type` junto con el nombre del tipo:
```
type Type_Name_Goes_Here {}
```
Dentro del ámbito del tipo, puede añadir campos que representen las características del objeto:
```
type Type_Name_Goes_Here {
# Add fields here
}
```
A continuación se muestra un ejemplo:
```
type Obj_Type_1 {
id: ID!
title: String
date: AWSDateTime
}
```
**nota**
En este paso, hemos añadido un tipo de objeto genérico con un campo `id` obligatorio almacenado como `ID`, un campo `title` almacenado como `String` y un campo `date` almacenado como `AWSDateTime`. Para ver una lista de tipos y campos, y lo que hacen, consulte [Esquemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html). Para ver una lista de escalares y lo que hacen, consulte [Referencia de tipos](https://docs.aws.amazon.com/appsync/latest/devguide/type-reference.html).
------
#### [ CLI ]
**nota**
Le recomendamos leer primero la versión de consola si aún no lo ha hecho.
+ Puede crear un tipo de objeto ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html).
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. La `definition` o el contenido de su tipo. En el ejemplo de la consola, esto era:
```
type Obj_Type_1 {
id: ID!
title: String
date: AWSDateTime
}
```
1. El `format` de su entrada. En este ejemplo, usaremos `SDL`.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "type Obj_Type_1{id: ID! title: String date: AWSDateTime}" --format SDL
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"type": {
"definition": "type Obj_Type_1{id: ID! title: String date: AWSDateTime}",
"name": "Obj_Type_1",
"arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Obj_Type_1",
"format": "SDL"
}
}
```
**nota**
En este paso, hemos añadido un tipo de objeto genérico con un campo `id` obligatorio almacenado como `ID`, un campo `title` almacenado como `String` y un campo `date` almacenado como `AWSDateTime`. Para ver una lista de tipos y campos, y lo que hacen, consulte [Esquemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html). Para ver una lista de escalares y lo que hacen, consulte [Referencia de tipos](https://docs.aws.amazon.com/appsync/latest/devguide/type-reference.html).
Por otra parte, puede que se haya dado cuenta de que introducir la definición directamente funciona para tipos más pequeños pero no es factible para añadir tipos más grandes o múltiples. Puede optar por añadir todo el contenido en un archivo `.graphql` y, a continuación, [pasarlo como entrada](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html).
------
#### [ CDK ]
**sugerencia**
[Antes de usar la CDK, le recomendamos que consulte la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/home.html) de la CDK junto con su referencia a AWS AppSync la misma.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
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 tipo, debe añadirlo a su archivo `.graphql`. El ejemplo de la consola era:
```
type Obj_Type_1 {
id: ID!
title: String
date: AWSDateTime
}
```
Puede añadir sus tipos directamente al esquema como cualquier otro archivo.
**nota**
Para usar los cambios realizados en la API de GraphQL, deberá volver a implementar la aplicación.
------
El [tipo de objeto](https://graphql.org/learn/schema/#object-types-and-fields) tiene campos que son de [tipo escalar](https://graphql.org/learn/schema/#scalar-types), como cadenas y números enteros. AWS AppSync también te permite usar tipos escalares mejorados, `AWSDateTime` además de los escalares básicos de GraphQL. Además, todos los campos que terminen con un signo de exclamación son obligatorios.
El tipo escalar `ID` en concreto es un identificador exclusivo que puede ser `String` o `Int`. Puede controlarlos en el código de resolución para la asignación automática.
Existen similitudes entre los tipos de objetos especiales, como `Query` y los tipos de objetos “normales”, como en el ejemplo anterior, en el sentido de que ambos utilizan la palabra clave `type` y se consideran objetos. Sin embargo, en el caso de los tipos de objetos especiales (`Query`, `Mutation`, y `Subscription`), su comportamiento es muy diferente, ya que se exponen como puntos de entrada a la API. También se centran más en dar forma a las operaciones que a los datos. Para obtener más información, consulte la sección sobre [tipos de consultas y mutaciones](https://graphql.org/learn/schema/#the-query-and-mutation-types).
En cuanto a los tipos de objetos especiales, el siguiente paso podría ser añadir uno o más para realizar operaciones con los datos con forma. En un escenario real, cada esquema de GraphQL debe tener al menos un tipo de consulta raíz para solicitar datos. Puede considerar la consulta como uno de los puntos de entrada (o puntos de conexión) de su servidor GraphQL. Añadamos una consulta como ejemplo.
------
#### [ Console ]
+ Para crear una consulta, basta con añadirla al archivo de esquema como cualquier otro tipo. Una consulta requeriría un tipo `Query` y una entrada en la raíz de la manera siguiente:
```
schema {
query: Name_of_Query
}
type Name_of_Query {
# Add field operation here
}
```
Ten en cuenta que *Name\$1of\$1Query* en un entorno de producción simplemente se llamará `Query` en la mayoría de los casos. Se recomienda mantenerlo en este valor. Dentro del tipo de consulta, puede añadir campos. Cada campo realizará una operación en la solicitud. El resultado es que la mayoría de estos campos, si no todos, se asociarán a un solucionador. Sin embargo, en esta sección o abordaremos eso. En cuanto al formato de la operación de campo, podría ser como este:
```
Name_of_Query(params): Return_Type # version with params
Name_of_Query: Return_Type # version without params
```
A continuación se muestra un ejemplo:
```
schema {
query: Query
}
type Query {
getObj: [Obj_Type_1]
}
type Obj_Type_1 {
id: ID!
title: String
date: AWSDateTime
}
```
**nota**
En este paso, agregamos un tipo `Query` y lo definimos en nuestra raíz de `schema`. Nuestro tipo `Query` definió un campo `getObj` que devuelve una lista de objetos `Obj_Type_1`. Tenga en cuenta que `Obj_Type_1` es el objeto del paso anterior. En el código de producción, sus operaciones de campo normalmente funcionarán con datos moldeados por objetos como `Obj_Type_1`. Además, campos como `getObj` suelen tener un solucionador para ejecutar la lógica empresarial. Este tema se tratará en otra sección.
Como nota adicional, agrega AWS AppSync automáticamente una raíz del esquema durante las exportaciones, por lo que técnicamente no es necesario agregarla directamente al esquema. Nuestro servicio procesará automáticamente los esquemas duplicados. Lo añadimos aquí como práctica recomendada.
------
#### [ CLI ]
**nota**
Le recomendamos leer primero la versión de consola si aún no lo ha hecho.
1. Cree una raíz de `schema` con una definición `query` ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html).
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. La `definition` o el contenido de su tipo. En el ejemplo de la consola, esto era:
```
schema {
query: Query
}
```
1. El `format` de su entrada. En este ejemplo, usaremos `SDL`.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "schema {query: Query}" --format SDL
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"type": {
"definition": "schema {query: Query}",
"name": "schema",
"arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/schema",
"format": "SDL"
}
}
```
**nota**
Tenga en cuenta que si no ha introducido algo correctamente en el comando `create-type`, puede actualizar la raíz del esquema (o cualquier tipo del esquema) ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html). En este ejemplo, cambiaremos temporalmente la raíz del esquema para que contenga una definición de `subscription`.
Para este comando en particular, deberá introducir varios parámetros:
El `api-id` de su API.
El `type-name` de su tipo. En el ejemplo de la consola, esto era `schema`.
La `definition` o el contenido de su tipo. En el ejemplo de la consola, esto era:
```
schema {
query: Query
}
```
El esquema después de añadir una `subscription` será como el siguiente:
```
schema {
query: Query
subscription: Subscription
}
```
El `format` de su entrada. En este ejemplo, usaremos `SDL`.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync update-type --api-id abcdefghijklmnopqrstuvwxyz --type-name schema --definition "schema {query: Query subscription: Subscription}" --format SDL
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"type": {
"definition": "schema {query: Query subscription: Subscription}",
"arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/schema",
"format": "SDL"
}
}
```
En este ejemplo, seguirá funcionando la adición de archivos preformateados.
1. Cree un tipo de `Query` ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html).
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. La `definition` o el contenido de su tipo. En el ejemplo de la consola, esto era:
```
type Query {
getObj: [Obj_Type_1]
}
```
1. El `format` de su entrada. En este ejemplo, usaremos `SDL`.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "type Query {getObj: [Obj_Type_1]}" --format SDL
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"type": {
"definition": "Query {getObj: [Obj_Type_1]}",
"name": "Query",
"arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Query",
"format": "SDL"
}
}
```
**nota**
En este paso, hemos añadido un tipo `Query` y lo hemos definido en su raíz de `schema`. Nuestro tipo `Query` ha definido un campo `getObj` que devuelve una lista de objetos `Obj_Type_1`.
En el código de raíz de `schema` `query: Query`, la parte `query:` indica que se ha definido una consulta en el esquema, mientras que la parte `Query` indica el nombre real del objeto especial.
------
#### [ CDK ]
**sugerencia**
[Antes de usar la CDK, te recomendamos que consultes la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/home.html) de la CDK junto con AWS AppSync su referencia.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
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.
Deberá añadir la consulta y la raíz del esquema al archivo `.graphql`. Nuestro caso era parecido al ejemplo siguiente, pero en este lo sustituirá con su código de esquema actual:
```
schema {
query: Query
}
type Query {
getObj: [Obj_Type_1]
}
type Obj_Type_1 {
id: ID!
title: String
date: AWSDateTime
}
```
Puede añadir sus tipos directamente al esquema como cualquier otro archivo.
**nota**
Actualizar la raíz del esquema es opcional. Lo hemos añadido a este ejemplo como práctica recomendada.
Para usar los cambios realizados en la API de GraphQL, deberá volver a implementar la aplicación.
------
Ahora ya ha visto un ejemplo de creación tanto de objetos como de objetos especiales (consultas). También ha visto cómo se pueden interconectar para describir datos y operaciones. Puede tener esquemas con solo la descripción de los datos y una o más consultas. Sin embargo, nos gustaría añadir otra operación para añadir datos al origen de datos. Vamos a añadir otro tipo de objeto especial denominado `Mutation` que modifica los datos.
------
#### [ Console ]
+ Una mutación se llamará `Mutation`. Como en `Query`, las operaciones de campo de dentro de `Mutation` describirán una operación y se asociarán a un solucionador. Tenga en cuenta también que debemos definirla en la raíz `schema` porque es un tipo de objeto especial. Aquí tiene un ejemplo de mutación:
```
schema {
mutation: Name_of_Mutation
}
type Name_of_Mutation {
# Add field operation here
}
```
Una mutación típica aparecerá en la raíz en forma de consulta. La mutación se define con la `type` palabra clave junto con el nombre. *Name\$1of\$1Mutation*normalmente se llamará así`Mutation`, por lo que recomendamos mantenerlo así. Cada campo realizará también una operación. En cuanto al formato de la operación de campo, podría ser como este:
```
Name_of_Mutation(params): Return_Type # version with params
Name_of_Mutation: Return_Type # version without params
```
A continuación se muestra un ejemplo:
```
schema {
query: Query
mutation: Mutation
}
type Obj_Type_1 {
id: ID!
title: String
date: AWSDateTime
}
type Query {
getObj: [Obj_Type_1]
}
type Mutation {
addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
}
```
**nota**
En este paso, hemos añadido un tipo `Mutation` con un campo `addObj`. Vamos a resumir lo que hace este campo:
```
addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
```
`addObj` está utilizando el objeto `Obj_Type_1` para realizar una operación. Esto es evidente debido a los campos, pero la sintaxis lo demuestra en el tipo de retorno `: Obj_Type_1`. Dentro de `addObj`, acepta los campos `id`, `title` y `date` del objeto `Obj_Type_1` como parámetros. Como puede ver, es muy parecido a la declaración de un método. Sin embargo, aún no hemos descrito el comportamiento de nuestro método. Como se ha afirmado antes, el esquema solo está ahí para definir cuáles serán los datos y las operaciones, no cómo funcionan. La lógica empresarial real se implementará más adelante, cuando creemos nuestros primeros solucionadores.
Una vez que haya terminado con su esquema, hay una opción para exportarlo como archivo `schema.graphql`. En el **editor de esquemas**, puede elegir **Exportar esquema** para descargar el archivo en un formato compatible.
Como nota adicional, agrega AWS AppSync automáticamente una raíz del esquema durante las exportaciones, por lo que técnicamente no es necesario agregarla directamente al esquema. Nuestro servicio procesará automáticamente los esquemas duplicados. Lo añadimos aquí como práctica recomendada.
------
#### [ CLI ]
**nota**
Le recomendamos leer primero la versión de consola si aún no lo ha hecho.
1. Actualice su esquema de raíz ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html).
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. El `type-name` de su tipo. En el ejemplo de la consola, esto era `schema`.
1. La `definition` o el contenido de su tipo. En el ejemplo de la consola, esto era:
```
schema {
query: Query
mutation: Mutation
}
```
1. El `format` de su entrada. En este ejemplo, usaremos `SDL`.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync update-type --api-id abcdefghijklmnopqrstuvwxyz --type-name schema --definition "schema {query: Query mutation: Mutation}" --format SDL
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"type": {
"definition": "schema {query: Query mutation: Mutation}",
"arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/schema",
"format": "SDL"
}
}
```
1. Cree un tipo de `Mutation` ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html).
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. La `definition` o el contenido de su tipo. En el ejemplo de la consola, esto era:
```
type Mutation {
addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
}
```
1. El `format` de su entrada. En este ejemplo, usaremos `SDL`.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "type Mutation {addObj(id: ID! title: String date: AWSDateTime): Obj_Type_1}" --format SDL
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"type": {
"definition": "type Mutation {addObj(id: ID! title: String date: AWSDateTime): Obj_Type_1}",
"name": "Mutation",
"arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation",
"format": "SDL"
}
}
```
------
#### [ CDK ]
**sugerencia**
[Antes de usar la CDK, te recomendamos que consultes la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/home.html) de la CDK junto con AWS AppSync su referencia.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
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.
Deberá añadir la consulta y la raíz del esquema al archivo `.graphql`. Nuestro caso era parecido al ejemplo siguiente, pero en este lo sustituirá con su código de esquema actual:
```
schema {
query: Query
mutation: Mutation
}
type Obj_Type_1 {
id: ID!
title: String
date: AWSDateTime
}
type Query {
getObj: [Obj_Type_1]
}
type Mutation {
addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
}
```
**nota**
Actualizar la raíz del esquema es opcional. Lo hemos añadido a este ejemplo como práctica recomendada.
Para usar los cambios realizados en la API de GraphQL, deberá volver a implementar la aplicación.
------
## Consideraciones opcionales: uso de enumeraciones como estados
Llegados a este punto, ya sabe cómo hacer un esquema básico. Sin embargo, hay muchas cosas que se pueden añadir para aumentar la funcionalidad del esquema. Una característica común que se encuentra en las aplicaciones es el uso de enumeraciones como estados. Puede usar una enumeración para forzar la elección de un valor específico de un conjunto de valores cuando se invoque. Esto es adecuado para cosas que sabe que no van a cambiar drásticamente durante largos períodos de tiempo. Hipotéticamente, podríamos añadir una enumeración que devuelva el código de estado o cadena en la respuesta.
Como ejemplo, supongamos que vamos a crear una aplicación de redes sociales que almacene los datos de las publicaciones de un usuario en el backend. Nuestro esquema contiene un tipo `Post` que representa los datos de una publicación individual:
```
type Post {
id: ID!
title: String
date: AWSDateTime
poststatus: PostStatus
}
```
Nuestra `Post` contendrá un `id` único, un título de `title`, una `date` de publicación y una enumeración denominada `PostStatus` que representa el estado de la publicación a medida que la aplicación la procesa. Para nuestras operaciones, tendremos una consulta que devolverá todos los datos de la publicación:
```
type Query {
getPosts: [Post]
}
```
También tendremos una mutación que añade publicaciones al origen de datos:
```
type Mutation {
addPost(id: ID!, title: String, date: AWSDateTime, poststatus: PostStatus): Post
}
```
Si observamos nuestro esquema, la enumeración `PostStatus` podría tener varios estados. Tal vez que queramos que los tres estados básicos se llamen `success` (publicación procesada correctamente), `pending` (publicación procesada) y `error` (publicación que no se puede procesar). Para añadir la enumeración, podemos hacer lo siguiente:
```
enum PostStatus {
success
pending
error
}
```
El esquema completo podría ser como este:
```
schema {
query: Query
mutation: Mutation
}
type Post {
id: ID!
title: String
date: AWSDateTime
poststatus: PostStatus
}
type Mutation {
addPost(id: ID!, title: String, date: AWSDateTime, poststatus: PostStatus): Post
}
type Query {
getPosts: [Post]
}
enum PostStatus {
success
pending
error
}
```
Si un usuario añade una `Post` en la aplicación, se llamará a la operación `addPost` para procesar esos datos. A medida que el solucionador adjunto a `addPost` procese los datos, actualizará continuamente `poststatus` con el estado de la operación. Cuando se consulte, `Post` contendrá el estado final de los datos. Tenga en cuenta que solo estamos describiendo cómo queremos que funcionen los datos en el esquema. Estamos haciendo muchas suposiciones sobre la implementación de nuestros solucionadores, que implementarán la lógica empresarial real para gestionar los datos a fin de cumplir con la solicitud.
## Consideraciones opcionales: suscripciones
Las suscripciones en AWS AppSync se invocan como respuesta a una mutación. Se puede configurar con un tipo `Subscription` y una directiva `@aws_subscribe()` en el esquema para indicar qué mutaciones invocan una o varias suscripciones. Para obtener más información sobre cómo configurar suscripciones, consulte [Datos en tiempo real](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html).
## Consideraciones opcionales: relaciones y paginación
Supongamos que tiene un millón de `Posts` almacenadas en una tabla de DynamoDB y desea devolver algunos de esos datos. Sin embargo, la consulta de ejemplo anterior solo devuelve todas las publicaciones. No le interesa buscarlas todas cada vez que realice una solicitud. Más bien, le interesa [paginarlas](https://graphql.org/learn/pagination/). Realice los cambios siguientes en su esquema:
+ En el campo `getPosts`, añada dos argumentos de entrada: `nextToken` (iterador) y `limit` (límite de iteración).
+ Añada un nuevo tipo de `PostIterator` que contenga los campos `Posts` (recupera la lista de objetos `Post`) y `nextToken` (iterador).
+ Modifique `getPosts` para que devuelva `PostIterator` y no una lista de objetos de `Post`.
```
schema {
query: Query
mutation: Mutation
}
type Post {
id: ID!
title: String
date: AWSDateTime
poststatus: PostStatus
}
type Mutation {
addPost(id: ID!, title: String, date: AWSDateTime, poststatus: PostStatus): Post
}
type Query {
getPosts(limit: Int, nextToken: String): PostIterator
}
enum PostStatus {
success
pending
error
}
type PostIterator {
posts: [Post]
nextToken: String
}
```
El tipo `PostIterator` le permite devolver una parte de la lista de objetos de `Post` y un `nextToken` para obtener la parte siguiente. Dentro de `PostIterator`, hay una lista de elementos de `Post` (`[Post]`) que se devuelve con un token de paginación (`nextToken`). En AWS AppSync, se conectaría a Amazon DynamoDB a través de un solucionador y se generaría automáticamente como un token cifrado. Así se convierte el valor del argumento `limit` en el parámetro `maxResults` y el argumento `nextToken` en el parámetro `exclusiveStartKey`. Para ver ejemplos y los ejemplos de plantillas integradas en la AWS AppSync consola, consulte [Resolver reference () JavaScript](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-js-version.html).
# 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), OpenSearch Amazon Service y puntos de enlace HTTP. Se puede configurar una AWS AppSync API 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 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 AWS AppSync consola, puede adjuntarle una fuente 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](https://docs.aws.amazon.com//appsync/latest/devguide/schema-launch-start.html).
En su lugar, analizaremos todas las fuentes de datos AWS AppSync 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](https://docs.aws.amazon.com/appsync/latest/devguide/data-source-components.html).
### 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 un elemento de la base row/record 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 datos de su aplicación. AWS AppSync le permite conectar las tablas de DynamoDB a la API de GraphQL para manipular los datos. Tomemos este [caso de uso](https://aws.amazon.com/blogs/mobile/new-real-time-multi-group-app-with-aws-amplify-graphql-build-a-twitter-community-clone/) 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 desencadenante puede ser cualquier cosa, como una aplicación que realiza una llamada a la API, un AWS servicio de tu 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](https://aws.amazon.com/blogs/mobile/building-a-graphql-api-with-java-and-aws-lambda/) 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 *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 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 reduce gran parte del trabajo de back-end, ya que proporciona escalabilidad mediante la AWS«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](https://aws.amazon.com/blogs/mobile/building-a-graphql-api-with-java-and-aws-lambda/) de la sección Lambda. En *la opción 3: AWS AppSync con Amazon RDS Resolver*, se presenta otra opción que consiste en vincular la API GraphQL directamente AWS AppSync a Amazon RDS. Mediante una [API de datos](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html), 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á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 los metadatos del cambio de estado de un evento (ID, región, número de cuenta, ARN, etc.). Cuando un evento coincide con el patrón de eventos, EventBridge lo enviará a través de la canalización hasta el servicio de destino (**objetivo**) y activará 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](https://aws.amazon.com/blogs/mobile/appsync-eventbridge/) 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 ubicada en ella. 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](https://aws.amazon.com/blogs/mobile/appsync-eventbridge/) 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á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 compatible con ACID, 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 archivos JSON denominados **documentos**. A continuación, puede consultar los datos del documento en el nodo.
### Puntos de conexión HTTP
Puedes usar puntos de enlace HTTP 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 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 una fuente de datos, puede vincularla al AWS AppSync servicio y, más específicamente, a la API.
------
#### [ Console ]
1. Inicie sesión en la [AppSyncconsola Consola de administración de AWS y ábrala](https://console.aws.amazon.com/appsync/).
1. En el **panel**, elija su API.
1. En la **barra lateral**, seleccione **Origen de datos**.
1. Elija **Crear origen de datos**.
1. Asigne un nombre al origen de datos. También puede asignarle una descripción, pero eso es opcional.
1. Elija el **tipo de origen de datos**.
1. 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](https://docs.aws.amazon.com/appsync/latest/devguide/conflict-detection-and-sync.html), 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.
Para OpenSearch ello, tendrás que elegir tu 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 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 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](#iam-trust-policy.title).
1. 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 [https://docs.aws.amazon.com/cli/latest/reference/appsync/create-data-source.html](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-data-source.html).
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. El `name` de su tabla.
1. 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 la CDK, te recomendamos que consultes la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/home.html) de la CDK junto con AWS AppSync su referencia.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
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í:
+ [ DynamoDbDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.DynamoDbDataSource.html)
+ [ EventBridgeDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.EventBridgeDataSource.html)
+ [ HttpDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.HttpDataSource.html)
+ [ LambdaDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.LambdaDataSource.html)
+ [ NoneDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.NoneDataSource.html)
+ [ OpenSearchDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.OpenSearchDataSource.html)
+ [ RdsDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.RdsDataSource.html)
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';
```
1. 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.
1. Para la mayoría de las fuentes de datos, especialmente AWS los servicios, creará 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 `?`). Consulte la documentación del CDK para ver qué accesorios se necesitan.
1. 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 AWS AppSync consola (`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ás que vincular la función de resolución a la fuente de datos manualmente en la AWS AppSync consola (si quieres seguir utilizando el valor de la consola`data_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.
------
### Política de confianza de IAM
Si utiliza una función de IAM existente para su 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:
------
#### [ JSON ]
****
```
{
"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`:
------
#### [ JSON ]
****
```
{
"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:
------
#### [ JSON ]
****
```
{
"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"
}
}
}
]
}
```
------
Puedes limitar el acceso a todos los AWS AppSync APIs usuarios de una región específica, por ejemplo`us-east-1`, mediante la siguiente política:
------
#### [ JSON ]
****
```
{
"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](https://docs.aws.amazon.com//appsync/latest/devguide/resolver-config-overview.html)), 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](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_manage_modify.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre el acceso de los AWS Lambda solucionadores entre cuentas AWS AppSync, consulte [Crear dispositivos de resolución multicuenta AWS Lambda](https://aws.amazon.com/blogs/mobile/appsync-lambda-cross-account/) para. AWS AppSync
# Configuración de solucionadores en AWS AppSync
En las secciones anteriores, vimos cómo crear el esquema de GraphQL y el origen de datos, para luego vincularlos juntos en el servicio de AWS AppSync. En su esquema, tal vez haya establecido uno o más campos (operaciones) en la consulta y la mutación. Si bien el esquema describía los tipos de datos que las operaciones solicitarían al origen de datos, no se implementó el comportamiento de esas operaciones con respecto a los datos.
El comportamiento de una operación se implementa siempre en el solucionador, que esta vinculado al campo que realiza la operación. Para obtener más información sobre el funcionamiento general de los solucionadores, consulte la página [Solucionadores](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html).
En AWS AppSync, su solucionador está vinculado a un tiempo de ejecución, que es el entorno en el que se ejecuta su solucionador. Los tiempos de ejecución determinan el lenguaje en el que se escribirá la resolución. Actualmente se admiten dos tiempos de ejecución: APPSYNC\$1JS (JavaScript) y Apache Velocity Template Language (VTL).
Al implementar los solucionadores, estos siguen una estructura general:
+ **Paso anterior**: cuando el cliente realiza una solicitud, los datos de esta se envían a los solucionadores de los campos de esquema que se usan (normalmente, las consultas, las mutaciones y las suscripciones). El solucionador empezará a procesar los datos de la solicitud con un controlador previo paso a paso, que permite realizar algunas operaciones de preprocesamiento antes de que los datos pasen por el solucionador.
+ **Funciones**: una vez ejecutado el paso anterior, la solicitud se pasa a la lista de funciones. La primera función de la lista se ejecuta conforme al origen de datos. Una función es un subconjunto del código de su solucionador, que contiene su propio controlador de solicitudes y respuestas. Un controlador de solicitudes toma los datos de la solicitud y realiza operaciones con el origen de datos. El controlador de respuestas procesa la respuesta del origen de datos antes de devolverla a la lista. Si hay más de una función, los datos de la solicitud se envían a la siguiente función de la lista que se ejecutará. Las funciones de la lista se ejecutan en serie en el orden definido por el desarrollador. Una vez ejecutadas todas las funciones, el resultado final se envía al paso posterior.
+ **Paso posterior**: el paso posterior es una función de controlador que permite realizar algunas operaciones finales en la respuesta de la función final antes de pasarla a la respuesta de GraphQL.
Este flujo es un ejemplo de un solucionador de canalizaciones. Los solucionadores de canalizaciones son compatibles con ambos tiempos de ejecución. Sin embargo, esta es una explicación simplificada de lo que pueden hacer los solucionadores de canalizaciones. Además, solo describimos una posible configuración del solucionador. Para obtener más información sobre las configuraciones de solucionador compatibles, consulte el artículo [Descripción general de los solucionadores de JavaScript](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html) para APPSYNC\$1JS o [Información general sobre las plantillas de mapeo de solucionador](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-overview.html) para VTL.
Como puede ver, los solucionadores son modulares. Para que los componentes del solucionador funcionen correctamente, deben poder observar el estado de la ejecución desde otros componentes. En la sección [Solucionadores](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html) ya hemos visto que a cada componente del solucionador se le puede pasar información crítica sobre el estado de la ejecución en forma de un conjunto de argumentos (`args`, `context`, etc.). En AWS AppSync, esto lo controla estrictamente el `context`. Se trata de un contenedor de la información acerca del campo que se está solucionando. Aquí se puede incluir de todo, desde los argumentos que se pasan hasta los resultados, pasando por los datos de autorización, los datos del encabezado, etc. Para obtener más información sobre el contexto, consulte [Referencia al objeto del contexto del solucionador](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) para APPSYNC\$1JS o [Referencia de contexto de las plantillas de mapeo del solucionador](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html) para VTL.
El contexto no es la única herramienta que puede utilizar para implementar su solucionador. AWS AppSync admite una amplia gama de utilidades para la generación de valor, el manejo de errores, el análisis, la conversión, etc. Puede ver una lista de utilidades [aquí](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference-js.html) para APPSYNC\$1JS o [aquí](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference.html) para VTL.
En las siguientes secciones, verá cómo configurar solucionadores en su API de GraphQL.
**Topics**
+ [Creación de consultas básicas (JavaScript)](configuring-resolvers-js.md)
+ [Creación de consultas básicas (VTL)](configuring-resolvers.md)
# Creación de consultas básicas (JavaScript)
Los solucionadores de GraphQL conectan los campos de un esquema de tipo a un origen de datos. Los solucionadores son el mecanismo mediante el cual se atienden las solicitudes.
Resolvers que se AWS AppSync utilizan JavaScript para convertir una expresión de GraphQL en un formato que pueda utilizar la fuente de datos. Como alternativa, las plantillas de asignación se pueden escribir en [Apache Velocity Template Language (VTL)](https://velocity.apache.org/engine/2.0/vtl-reference.html) para convertir una expresión de GraphQL en un formato que el origen de datos pueda utilizar.
En esta sección se describe cómo configurar los resolutores mediante. JavaScript La sección [Tutoriales de resolución (JavaScript)](https://docs.aws.amazon.com/appsync/latest/devguide/tutorials-js.html) proporciona tutoriales detallados sobre cómo implementar resolutores utilizando. JavaScript La sección de [referencia del solucionador (JavaScript)](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-js-version.html) proporciona una explicación de las operaciones de utilidad que se pueden utilizar con los JavaScript resolutores.
Recomendamos seguir esta guía antes de intentar utilizar alguno de los tutoriales mencionados anteriormente.
En esta sección se mostrará cómo crear y configurar solucionadores para consultas y mutaciones.
**nota**
En esta guía se supone que ha creado su esquema y que tiene al menos una consulta o mutación. Si busca suscripciones (datos en tiempo real), consulte [esta](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html) guía.
En esta sección, proporcionaremos algunos pasos generales para configurar solucionadores junto con un ejemplo que usa el esquema siguiente:
```
// schema.graphql file
input CreatePostInput {
title: String
date: AWSDateTime
}
type Post {
id: ID!
title: String
date: AWSDateTime
}
type Mutation {
createPost(input: CreatePostInput!): Post
}
type Query {
getPost: [Post]
}
```
## Creación de solucionadores de consultas básicos
En esta sección se mostrará cómo crear un solucionador de consultas básico.
------
#### [ Console ]
1. Inicie sesión en la [AppSyncconsola Consola de administración de AWS](https://console.aws.amazon.com/appsync/) y ábrala.
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Esquema**.
1. Introduzca los detalles del esquema y el origen de datos. Consulte las secciones [Diseño del esquema](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) y [Asociar un origen de datos](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) para obtener más información.
1. Junto al editor **Esquemas**, hay una ventana llamada **Solucionadores**. Este cuadro contiene una lista de los tipos y campos definidos en la ventana **Esquema**. Puede asociar solucionadores a los campos. Lo más probable es que asocie solucionadores a sus operaciones de campo. En esta sección se analizarán las configuraciones de consultas sencillas. En el tipo **Consulta**, seleccione **Asociar** junto al campo de la consulta.
1. En la página **Asociar solucionador**, en **Tipo de solucionador**, puede elegir entre solucionadores de canalización o unitarios. Para obtener más información sobre estos tipos, consulte [Solucionadores](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html). En esta guía se utilizará `pipeline resolvers`.
**sugerencia**
Al crear solucionadores de canalización, sus orígenes de datos se asociarán a las funciones de canalización. Las funciones se crean después de crear el propio solucionador de canalizaciones, por lo que no existe la opción de configurarlo en esta página. Si utiliza un solucionador unitario, el origen de datos se vincula directamente al solucionador, por lo que deberá configurarlo en esta página.
Para el **tiempo de ejecución de Resolver**, selecciona `APPSYNC_JS` habilitar el JavaScript tiempo de ejecución.
1. Puede habilitar el [almacenamiento en caché](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html) para esta API. También recomendamos desactivar esta característica por el momento. Seleccione **Crear**.
1. En la página **Editar solucionador**, hay un editor de código llamado **Código de solucionador** que le permite implementar la lógica para el controlador y la respuesta del solucionador (antes y después de los pasos). Para obtener más información, consulte la [descripción general de los JavaScript resolutores](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html).
**nota**
En nuestro ejemplo, vamos a dejar la solicitud en blanco y la respuesta establecida para devolver el último resultado del origen de datos del [contexto](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html):
```
import {util} from '@aws-appsync/utils';
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
```
Bajo esta sección, hay una tabla llamada **Funciones**. Las funciones permiten implementar código que se puede reutilizar en varios solucionadores. En lugar de tener que reescribir o copiar el código constantemente, puede almacenar el código fuente como una función para añadirla a un solucionador siempre que lo necesite.
Las funciones constituyen la mayor parte de la lista de operaciones de una canalización. Al utilizar varias funciones en un solucionador, se establece el orden de las funciones y estas se ejecutan en ese orden en secuencia. Se ejecutan después de la función de solicitud y antes de que comience la función de respuesta.
Para añadir una función nueva, en **Funciones**, seleccione **Añadir función** y, a continuación, **Crear nueva función**. Como alternativa, puede que vea el botón **Crear función** para seleccionarlo.
1. Elija un origen de datos. Será el origen de datos en el que actuará el solucionador.
**nota**
En nuestro ejemplo, asociamos un solucionador para `getPost`, que recupera un objeto `Post` según el `id`. Supongamos que ya hemos configurado una tabla de DynamoDB para este esquema. Su clave de partición está establecida en `id` y está vacía.
1. Introduzca un `Function name`.
1. En **Código de función**, deberá implementar el comportamiento de la función. Esto puede resultar confuso, pero cada función tendrá su propio controlador local de solicitudes y respuestas. Se ejecuta la solicitud, luego se invoca el origen de datos para gestionar la solicitud y, a continuación, el controlador de respuestas procesa la respuesta del origen de datos. El resultado se almacena en el objeto de [contexto](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html). Después, se ejecutará la siguiente función de la lista o se pasará al controlador de respuestas posterior al paso si es el último.
**nota**
En nuestro ejemplo, asociamos un solucionador a `getPost`, que obtiene una lista de objetos `Post` del origen de datos. Nuestra función de solicitud solicitará los datos de nuestra tabla, la tabla pasará su respuesta al contexto (ctx) y, a continuación, la respuesta devolverá el resultado en el contexto. AWS AppSync Su punto fuerte reside en su interconexión con otros servicios. AWS Dado que utilizamos DynamoDB, tenemos un [conjunto de operaciones](https://docs.aws.amazon.com/appsync/latest/devguide/js-resolver-reference-dynamodb.html) para simplificar este tipo de acciones. También tenemos algunos ejemplos repetitivos para otros tipos de orígenes de datos.
Nuestro código será como este:
```
import { util } from '@aws-appsync/utils';
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
return { operation: 'Scan' };
}
/**
* return a list of scanned post items
*/
export function response(ctx) {
return ctx.result.items;
}
```
En este paso, hemos añadido dos funciones:
`request`: el controlador de solicitudes realiza la operación de recuperación en el origen de datos. El argumento contiene el objeto de contexto (`ctx`) o datos que están disponibles para todos los solucionadores que realizan una operación determinada. Por ejemplo, puede contener datos de autorización, los nombres de los campos que se están resolviendo, etc. La instrucción return realiza una operación [https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-scan](https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-scan) (vea ejemplos [aquí](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html)). Dado que trabajamos con DynamoDB, podemos usar algunas de las operaciones de ese servicio. El escaneo realiza una búsqueda básica de todos los elementos de nuestra tabla. El resultado de esta operación se almacena en el objeto de contexto como un contenedor de `result` antes de pasarlo al controlador de respuestas. La `request` se ejecuta antes de la respuesta en la canalización.
`response`: el controlador de respuestas que devuelve la salida de `request`. El argumento es el objeto de contexto actualizado y la declaración de retorno es `ctx.prev.result`. En este punto de la guía, es posible que no esté familiarizado con este valor. `ctx` hace referencia al objeto de contexto. `prev`, a la operación anterior en la canalización, que era nuestra `request`. `result` contiene los resultados del solucionador a medida que se desplaza por la canalización. Si lo junta todo, `ctx.prev.result` devuelve el resultado de la última operación realizada, que fue el controlador de solicitudes.
1. Cuando haya terminado, elija **Crear**.
1. De vuelta a la pantalla de solucionador, en **Funciones**, seleccione el menú desplegable **Añadir función** y añada la función a su lista de funciones.
1. Seleccione **Guardar** para actualizar el solucionador.
------
#### [ CLI ]
**Para añadir su función**
+ Cree una función para su solucionador de canalizaciones mediante el comando `[create-function](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-function.html)`.
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. El `name` de la función de la consola. AWS AppSync
1. El `data-source-name` o el nombre del origen de datos que la función utilizará. Ya debe estar creado y vinculado a su API de GraphQL en el servicio de AWS AppSync .
1. El `runtime` o el entorno y el idioma de la función. Para JavaScript, el nombre debe ser`APPSYNC_JS`, y el tiempo de ejecución,`1.0.0`.
1. El `code` o los controladores de solicitud y respuesta de su función. Si bien puede escribirlo manualmente, es mucho más fácil agregarlo a un archivo.txt (o un formato similar) y luego pasarlo como argumento.
**nota**
Nuestro código de consulta estará en un archivo que se transfiere como argumento:
```
import { util } from '@aws-appsync/utils';
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
return { operation: 'Scan' };
}
/**
* return a list of scanned post items
*/
export function response(ctx) {
return ctx.result.items;
}
```
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-function \
--api-id abcdefghijklmnopqrstuvwxyz \
--name get_posts_func_1 \
--data-source-name table-for-posts \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file://~/path/to/file/{filename}.{fileType}
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"functionConfiguration": {
"functionId": "ejglgvmcabdn7lx75ref4qeig4",
"functionArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/functions/ejglgvmcabdn7lx75ref4qeig4",
"name": "get_posts_func_1",
"dataSourceName": "table-for-posts",
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output goes here"
}
}
```
**nota**
Asegúrese de grabar el `functionId` en algún lugar, ya que se utilizará para asociar la función al solucionador.
**Para crear su primer solucionador**
+ Cree una función de canalización para `Query` ejecutando el comando `[create-resolver](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)`.
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. El `type-name` o el tipo de objeto especial de su esquema (consulta, mutación, suscripción).
1. El `field-name` o la operación de campo de dentro del tipo de objeto especial al que desee asociar el solucionador.
1. El `kind`, que especifica un solucionador unitario o de canalización. Configúrelo en `PIPELINE` para habilitar las funciones de canalización.
1. La `pipeline-config` o las funciones que se van a asociar al solucionador. Asegúrese de conocer los valores de `functionId` de sus funciones. El orden de la lista es importante.
1. El`runtime`, que era `APPSYNC_JS` (JavaScript). La `runtimeVersion` actualmente es `1.0.0`.
1. El `code`, que contiene los controladores de los pasos de antes y de después.
**nota**
Nuestro código de consulta estará en un archivo que se transfiere como argumento:
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
const { id, ...values } = ctx.args;
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({ id }),
attributeValues: util.dynamodb.toMapValues(values),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-resolver \
--api-id abcdefghijklmnopqrstuvwxyz \
--type-name Query \
--field-name getPost \
--kind PIPELINE \
--pipeline-config functions=ejglgvmcabdn7lx75ref4qeig4 \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file:///path/to/file/{filename}.{fileType}
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"resolver": {
"typeName": "Mutation",
"fieldName": "getPost",
"resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation/resolvers/getPost",
"kind": "PIPELINE",
"pipelineConfig": {
"functions": [
"ejglgvmcabdn7lx75ref4qeig4"
]
},
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output goes here"
}
}
```
------
#### [ CDK ]
**sugerencia**
[Antes de utilizar la CDK, le recomendamos que consulte la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/home.html) de la CDK junto con AWS AppSync su referencia.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
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.
Una aplicación básica necesitará lo siguiente:
1. Directivas de importación de servicios
1. Código de esquema
1. Generador de orígenes de datos
1. Código de función
1. Código de solucionador
En las secciones [Diseñar el esquema](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) y [Asociar un origen de datos](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html), sabemos que el archivo de pila incluirá las directivas de importación del siguiente formato:
```
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'
```
**nota**
En las secciones anteriores, solo explicamos cómo importar AWS AppSync componentes fijos. En código real, deberá importar más servicios simplemente para ejecutar la aplicación. En nuestro ejemplo, si tuviéramos que crear una aplicación CDK muy sencilla, al menos importaríamos el AWS AppSync servicio junto con nuestra fuente de datos, que era una tabla de DynamoDB. También necesitaríamos importar otros constructos para implementar la aplicación:
```
import * as cdk from 'aws-cdk-lib';
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { Construct } from 'constructs';
```
Resumamos cada uno de estos elementos:
`import * as cdk from 'aws-cdk-lib';`: permite definir la aplicación del CDK y sus constructos, como la pila. También contiene funciones de utilidad útiles para nuestra aplicación, como la manipulación de metadatos. Si conoce esta directiva de importación, pero se pregunta por qué la biblioteca principal de cdk no se utiliza aquí, consulte la página [Migración](https://docs.aws.amazon.com/cdk/v2/guide/migrating-v2.html).
`import * as appsync from 'aws-cdk-lib/aws-appsync';`: importa el [servicio de AWS AppSync](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html).
`import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';`: importa el [servicio de DynamoDB](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_dynamodb-readme.html).
`import { Construct } from 'constructs';`: lo necesitamos para definir el [constructo](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html) raíz.
El tipo de importación depende de los servicios que llame. Te recomendamos consultar la documentación del CDK para ver ejemplos. El esquema de la parte superior de la página será un archivo independiente en su aplicación de CDK, en forma de archivo `.graphql`. En el archivo de pila, podemos asociarlo a un nuevo GraphQL mediante el siguiente formulario:
```
const add_api = new appsync.GraphqlApi(this, 'graphQL-example', {
name: 'my-first-api',
schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema.graphql')),
});
```
**nota**
En el ámbito `add_api`, añadiremos una nueva API de GraphQL con la palabra clave `new` seguida de `appsync.GraphqlApi(scope: Construct, id: string , props: GraphqlApiProps)`. Nuestro ámbito es `this`, el identificador de CFN es `graphQL-example`, y nuestros accesorios son `my-first-api` (nombre de la API en la consola) y `schema.graphql` (la ruta absoluta al archivo de esquema).
Para añadir un origen de datos, añádala primero a la pila. Luego, asóciela a la API de GraphQL mediante el método específico del origen. La asociación se producirá cuando ponga en funcionamiento su solucionador. Mientras tanto, usemos un ejemplo para crear la tabla de DynamoDB con `dynamodb.Table`:
```
const add_ddb_table = new dynamodb.Table(this, 'posts-table', {
partitionKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
});
```
**nota**
Si usáramos esto en nuestro ejemplo, añadiríamos una nueva tabla de DynamoDB con el identificador de CFN de `posts-table` y una clave de partición de `id (S)`.
A continuación, debemos implementar nuestro solucionador en el archivo de pila. A continuación, se muestra un ejemplo de una consulta sencilla que busca todos los elementos de una tabla de DynamoDB:
```
const add_func = new appsync.AppsyncFunction(this, 'func-get-posts', {
name: 'get_posts_func_1',
add_api,
dataSource: add_api.addDynamoDbDataSource('table-for-posts', 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,
});
new appsync.Resolver(this, 'pipeline-resolver-get-posts', {
add_api,
typeName: 'Query',
fieldName: 'getPost',
code: appsync.Code.fromInline(`
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
pipelineConfig: [add_func],
});
```
**nota**
En primer lugar, creamos una función llamada `add_func`. Este orden de creación puede parecer un poco contradictorio, pero hay que crear las funciones en el solucionador de canalizaciones antes de crear el solucionador propiamente dicho. Una función tiene el siguiente formato:
```
AppsyncFunction(scope: Construct, id: string, props: AppsyncFunctionProps)
```
Nuestro alcance era `this`, nuestro identificador de CFN era `func-get-posts` y nuestros accesorios contenían los detalles reales de la función. Dentro de los accesorios, hemos incluido:
La `name` de la función que estará presente en la AWS AppSync consola (). `get_posts_func_1`
La API de GraphQL que hemos creado antes (`add_api`).
El origen de datos; este es el punto en el que vinculamos el origen de datos al valor de la API GraphQL y, a continuación, la asociamos a la función. Tomamos la tabla que hemos creado (`add_ddb_table`) y la asociamos a la API GraphQL (`add_api`) mediante uno de los métodos de `GraphqlApi` ([https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.GraphqlApi.html#addwbrdynamowbrdbwbrdatawbrsourceid-table-options](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.GraphqlApi.html#addwbrdynamowbrdbwbrdatawbrsourceid-table-options)). El valor del identificador (`table-for-posts`) es el nombre del origen de datos de la consola de AWS AppSync . Para obtener una lista de métodos específicos del origen, consulte las páginas siguientes:
[ DynamoDbDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.DynamoDbDataSource.html)
[ EventBridgeDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.EventBridgeDataSource.html)
[ HttpDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.HttpDataSource.html)
[ LambdaDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.LambdaDataSource.html)
[ NoneDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.NoneDataSource.html)
[ OpenSearchDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.OpenSearchDataSource.html)
[ RdsDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.RdsDataSource.html)
El código contiene los controladores de solicitudes y respuestas de nuestra función, que son fáciles de escanear y devolver.
El tiempo de ejecución especifica que queremos usar la versión 1.0.0 del tiempo de ejecución APPSYNC\$1JS. Tenga en cuenta que actualmente esta es la única versión disponible para APPSYNC\$1JS.
Luego, debemos asociar la función al solucionador de canalización. Hemos creado nuestro solucionador usando este formulario:
```
Resolver(scope: Construct, id: string, props: ResolverProps)
```
Nuestro alcance era `this`, nuestro identificador de CFN era `pipeline-resolver-get-posts` y nuestros accesorios contenían los detalles reales de la función. Dentro de los accesorios, hemos incluido:
La API de GraphQL que hemos creado antes (`add_api`).
El nombre del tipo de objeto especial; se trata de una operación de consulta, por lo que simplemente hemos añadido el valor `Query`.
El nombre de campo (`getPost`) es el nombre del campo del esquema en el tipo `Query`.
El código contiene sus controladores de antes y después. Nuestro ejemplo simplemente devuelve los resultados que estaban en el contexto después de que la función realizara su operación.
El tiempo de ejecución especifica que queremos usar la versión 1.0.0 del tiempo de ejecución APPSYNC\$1JS. Tenga en cuenta que actualmente esta es la única versión disponible para APPSYNC\$1JS.
La configuración de la canalización contiene la referencia a la función que hemos creado (`add_func`).
------
Para resumir lo que ocurrió en este ejemplo, vio una AWS AppSync función que implementaba un controlador de solicitudes y respuestas. La función se ha encargado de interactuar con el origen de datos. El controlador de solicitudes envió una `Scan` operación a AWS AppSync, indicándole qué operación debía realizar en la fuente de datos de DynamoDB. El controlador de respuestas ha devuelto la lista de elementos (`ctx.result.items`). A continuación, la lista de elementos se ha asignado automáticamente al tipo GraphQL de `Post`.
## Creación de solucionadores de mutaciones básicos
En esta sección se mostrará cómo crear un solucionador de mutaciones básico.
------
#### [ Console ]
1. [Inicie sesión en la consola Consola de administración de AWS y ábrala. AppSync](https://console.aws.amazon.com/appsync/)
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Esquema**.
1. En la sección **Solucionadores** y el tipo **Mutación**, seleccione **Asociar** junto al campo.
**nota**
En nuestro ejemplo, vamos a asociar un solucionador para `createPost`, que añade un objeto `Post` a nuestra table. Supongamos que utilizamos la misma tabla de DynamoDB de la última sección. Su clave de partición está establecida en `id` y está vacía.
1. En la página **Asociar solucionador**, en **Tipo de solucionador**, elija `pipeline resolvers`. Le recordamos que puede encontrar más información sobre los solucionadores [aquí](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html). Para el **tiempo de ejecución de Resolver**, selecciona `APPSYNC_JS` habilitar el JavaScript tiempo de ejecución.
1. Puede habilitar el [almacenamiento en caché](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html) para esta API. También recomendamos desactivar esta característica por el momento. Seleccione **Crear**.
1. Seleccione **Añadir función** y, a continuación, **Crear nueva función**. Como alternativa, puede que vea el botón **Crear función** para seleccionarlo.
1. Elija el origen su origen de datos. Debería ser el origen cuyos datos va a manipular con la mutación.
1. Introduzca un `Function name`.
1. En **Código de función**, deberá implementar el comportamiento de la función. Se trata de una mutación, por lo que lo ideal es que la solicitud realice alguna operación de cambio de estado en el origen de datos invocado. La función de respuesta procesará el resultado.
**nota**
`createPost` va a añadir o “poner” una nueva `Post` en la tabla con nuestros parámetros como datos. Podríamos añadir algo parecido a esto:
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({id: util.autoId()}),
attributeValues: util.dynamodb.toMapValues(ctx.args.input),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
En este paso, hemos añadido también las funciones `request` y `response`:
`request`: el controlador de solicitudes acepta el contexto como argumento. La instrucción return del controlador de solicitudes ejecuta un comando [https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-putitem](https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-putitem), que es una operación de DynamoDB integrada (consulte [aquí](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-2.html) o [aquí](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html#WorkingWithItems.WritingData) para ver ejemplos). El comando `PutItem` añade un objeto de `Post` a nuestra tabla de DynamoDB tomando el valor `key` de la partición (generado automáticamente por `util.autoid()`) y los `attributes` de la entrada del argumento de contexto (son los valores que transferiremos en nuestra solicitud). La `key` es el `id` y `attributes` son los argumentos de los campos `date` y `title`. Ambos se preformatean mediante el elemento auxiliar [https://docs.aws.amazon.com//appsync/latest/devguide/dynamodb-helpers-in-util-dynamodb-js.html#utility-helpers-in-toMap-js](https://docs.aws.amazon.com//appsync/latest/devguide/dynamodb-helpers-in-util-dynamodb-js.html#utility-helpers-in-toMap-js) para que funcionen con la tabla de DynamoDB.
`response`: la respuesta acepta el contexto actualizado y devuelve el resultado del controlador de solicitudes.
1. Cuando haya terminado, elija **Crear**.
1. De vuelta a la pantalla de solucionador, en **Funciones**, seleccione el menú desplegable **Añadir función** y añada la función a su lista de funciones.
1. Seleccione **Guardar** para actualizar el solucionador.
------
#### [ CLI ]
**Para añadir su función**
+ Cree una función para su solucionador de canalizaciones mediante el comando `[create-function](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-function.html)`.
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. El `name` de la función de la AWS AppSync consola.
1. El `data-source-name` o el nombre del origen de datos que la función utilizará. Ya debe estar creado y vinculado a su API de GraphQL en el servicio de AWS AppSync .
1. El `runtime` o el entorno y el idioma de la función. Para JavaScript, el nombre debe ser`APPSYNC_JS`, y el tiempo de ejecución,`1.0.0`.
1. El `code` o los controladores de solicitud y respuesta de su función. Si bien puede escribirlo manualmente, es mucho más fácil añadirlo a un archivo.txt (o un formato similar) y luego transferirlo como argumento.
**nota**
Nuestro código de consulta estará en un archivo que se transfiere como argumento:
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({id: util.autoId()}),
attributeValues: util.dynamodb.toMapValues(ctx.args.input),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-function \
--api-id abcdefghijklmnopqrstuvwxyz \
--name add_posts_func_1 \
--data-source-name table-for-posts \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file:///path/to/file/{filename}.{fileType}
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"functionConfiguration": {
"functionId": "vulcmbfcxffiram63psb4dduoa",
"functionArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/functions/vulcmbfcxffiram63psb4dduoa",
"name": "add_posts_func_1",
"dataSourceName": "table-for-posts",
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output foes here"
}
}
```
**nota**
Asegúrese de grabar el `functionId` en algún lugar, ya que se utilizará para asociar la función al solucionador.
**Para crear su primer solucionador**
+ Cree una función de canalización para `Mutation` ejecutando el comando `[create-resolver](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)`.
Para este comando en particular, deberá introducir varios parámetros:
1. El `api-id` de su API.
1. El `type-name` o el tipo de objeto especial de su esquema (consulta, mutación, suscripción).
1. El `field-name` o la operación de campo de dentro del tipo de objeto especial al que desee asociar el solucionador.
1. El `kind`, que especifica un solucionador unitario o de canalización. Configúrelo en `PIPELINE` para habilitar las funciones de canalización.
1. La `pipeline-config` o las funciones que se van a asociar al solucionador. Asegúrese de conocer los valores de `functionId` de sus funciones. El orden de la lista es importante.
1. El`runtime`, que era `APPSYNC_JS` (JavaScript). La `runtimeVersion` actualmente es `1.0.0`.
1. El `code`, que contiene los pasos de antes y de después.
**nota**
Nuestro código de consulta estará en un archivo que se transfiere como argumento:
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
const { id, ...values } = ctx.args;
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({ id }),
attributeValues: util.dynamodb.toMapValues(values),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-resolver \
--api-id abcdefghijklmnopqrstuvwxyz \
--type-name Mutation \
--field-name createPost \
--kind PIPELINE \
--pipeline-config functions=vulcmbfcxffiram63psb4dduoa \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file:///path/to/file/{filename}.{fileType}
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"resolver": {
"typeName": "Mutation",
"fieldName": "createPost",
"resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation/resolvers/createPost",
"kind": "PIPELINE",
"pipelineConfig": {
"functions": [
"vulcmbfcxffiram63psb4dduoa"
]
},
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output goes here"
}
}
```
------
#### [ CDK ]
**sugerencia**
[Antes de utilizar la CDK, le recomendamos que consulte la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/home.html) de la CDK junto con AWS AppSync su referencia.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
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 realizar una mutación, si usted se encuentra en el mismo proyecto, puede añadirla al archivo de pila como la consulta. Esta es una función modificada y un solucionador para una mutación que añade una nueva `Post` a la tabla:
```
const add_func_2 = new appsync.AppsyncFunction(this, 'func-add-post', {
name: 'add_posts_func_1',
add_api,
dataSource: add_api.addDynamoDbDataSource('table-for-posts-2', add_ddb_table),
code: appsync.Code.fromInline(`
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({id: util.autoId()}),
attributeValues: util.dynamodb.toMapValues(ctx.args.input),
};
}
export function response(ctx) {
return ctx.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
});
new appsync.Resolver(this, 'pipeline-resolver-create-posts', {
add_api,
typeName: 'Mutation',
fieldName: 'createPost',
code: appsync.Code.fromInline(`
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
pipelineConfig: [add_func_2],
});
```
**nota**
Como esta mutación y la consulta tienen una estructura similar, nos limitaremos a explicar los cambios que hemos hecho para realizar la mutación.
En la función, hemos cambiado el identificador de CFN por `func-add-post` y el nombre por `add_posts_func_1` a para reflejar el hecho de que estamos añadiendo `Posts` a la tabla. En la fuente de datos, hicimos una nueva asociación con nuestra tabla (`add_ddb_table`) de la AWS AppSync consola, `table-for-posts-2` ya que el `addDynamoDbDataSource` método así lo requiere. Tenga en cuenta que esta nueva asociación sigue utilizando la misma tabla que creamos anteriormente, pero ahora tenemos dos conexiones a ella en la AWS AppSync consola: una para la consulta as `table-for-posts` y otra para la mutación as`table-for-posts-2`. El código se ha modificado para añadir una `Post` mediante la generación automática de su valor de `id` y la aceptación de la entrada de un cliente para el resto de los campos.
En el solucionador, hemos cambiado el valor del identificador por `pipeline-resolver-create-posts` para reflejar el hecho de que estamos añadiendo `Posts` a la tabla. Para reflejar la mutación en el esquema, se cambiado el nombre del tipo por `Mutation`, y el nombre, `createPost`. La configuración de la canalización se ha establecido en nuestra nueva función de mutación `add_func_2`.
------
Para resumir lo que ocurre en este ejemplo, convierte AWS AppSync automáticamente los argumentos definidos en el `createPost` campo del esquema de GraphQL en operaciones de DynamoDB. El ejemplo almacena los registros en DynamoDB mediante una clave de `id`, que se crea automáticamente con nuestro texto auxiliar `util.autoId()`. Todos los demás campos que pase a los argumentos de contexto (`ctx.args.input`) a partir de solicitudes realizadas en la AWS AppSync consola o de otro modo se almacenarán como atributos de la tabla. Tanto la clave como los atributos se asignan automáticamente a un formato de DynamoDB compatible mediante el texto auxiliar `util.dynamodb.toMapValues(values)`.
AWS AppSync también admite flujos de trabajo de prueba y depuración para la edición de resoluciones. Puede usar un objeto `context` simulado para ver el valor transformado de la plantilla antes de invocarlo. De forma opcional, puede ver la solicitud completa en un origen de datos de forma interactiva cuando ejecute una consulta. [Para obtener más información, consulte [Probar y depurar solucionadores (JavaScript) y Supervisión y registro](https://docs.aws.amazon.com/appsync/latest/devguide/test-debug-resolvers-js.html).](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html#aws-appsync-monitoring)
## Solucionadores avanzados
Si sigue la sección de paginación opcional de [Diseño del esquema](designing-your-schema.md#aws-appsync-designing-your-schema), deberá añadir el solucionador a la solicitud para poder utilizar la paginación. En nuestro ejemplo, se ha utilizado una paginación de consultas llamada `getPosts` para devolver solo una parte de los elementos solicitados a la vez. Nuestro código de solucionador en ese campo puede ser como este:
```
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
const { limit = 20, nextToken } = ctx.args;
return { operation: 'Scan', limit, nextToken };
}
/**
* @returns the result of the `put` operation
*/
export function response(ctx) {
const { items: posts = [], nextToken } = ctx.result;
return { posts, nextToken };
}
```
En la solicitud, transferimos el contexto de esta. `limit`El nuestro es*20*, lo que significa que devolvemos hasta 20 `Posts` en la primera consulta. Nuestro cursor `nextToken` está fijo en la primera entrada de `Post` en el origen de datos. Se transfieren a los argumentos. A continuación, la solicitud escanea desde la primera `Post` hasta el número límite de escaneo. El origen de datos almacena el resultado en el contexto, que se transfiere a la respuesta. La respuesta devuelve las `Posts` recuperadas y, a continuación, establece el `nextToken` en la entrada de la `Post` que se encuentra justo después del límite. La siguiente solicitud se envía para hacer exactamente lo mismo, pero empezando por el desplazamiento justo después de la primera consulta. Tenga en cuenta que este tipo de solicitudes se realizan de forma secuencial y no en paralelo.
# Probar y depurar resolutores en AWS AppSync () JavaScript
AWS AppSync ejecuta resolutores en un campo GraphQL contra una fuente de datos. Cuando se trabaja con solucionadores de canalizaciones, las funciones interactúan con los orígenes de datos. Como se describe en la [descripción general de los JavaScript resolutores](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html), las funciones se comunican con las fuentes de datos mediante controladores de solicitudes y respuestas escritos JavaScript y que se ejecutan en tiempo de ejecución. `APPSYNC_JS` Esto le permite proporcionar lógica y condiciones personalizadas antes y después de comunicarse con el origen de datos.
Para ayudar a los desarrolladores a escribir, probar y depurar estos resolutores, la AWS AppSync consola también proporciona herramientas para crear una solicitud y una respuesta de GraphQL con datos simulados para cada solucionador de campo individual. Además, puedes realizar consultas, mutaciones y suscripciones en la AWS AppSync consola y ver un registro detallado de toda la solicitud de Amazon CloudWatch. Esto incluye los resultados del origen de datos.
## Prueba con datos simulados
Cuando se invoca a un solucionador de GraphQL, este contiene un objeto `context` que incluye información útil sobre la solicitud. Por ejemplo, contiene los argumentos de un cliente, información de identidad y datos del campo principal de GraphQL. También almacena los resultados del origen de datos, que puede usar en el controlador de respuestas. Si desea más información acerca de esta estructura y las utilidades auxiliares disponibles para programar, consulte [Resolver context object reference](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html).
Al escribir o editar una función de solucionador, puede pasar un objeto *simulado* o *de contexto de prueba* al editor de la consola. Esto le permite ver cómo se evalúan los controladores de solicitudes y de respuestas sin que se utilice en realidad ningún origen de datos. Por ejemplo, puede transferir un argumento `firstname: Shaggy` de prueba y ver cómo se evalúa cuando utiliza `ctx.args.firstname` en el código de la plantilla. También puede probar la evaluación de cualquier utilidad auxiliar, como `util.autoId()` o `util.time.nowISO8601()`.
### Prueba de solucionadores
En este ejemplo, se utilizará la AWS AppSync consola para probar los resolutores.
1. Inicie sesión en la [AppSyncconsola Consola de administración de AWS](https://console.aws.amazon.com/appsync/) y ábrala.
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Funciones**.
1. Seleccione una función existente.
1. En la parte superior de la página **Actualizar función**, seleccione **Seleccionar contexto de prueba** y, a continuación, **Crear nuevo contexto**.
1. Seleccione un objeto de contexto de ejemplo o rellene el JSON manualmente en la ventana **Configurar contexto de prueba** que aparece a continuación.
1. Introduzca un **Nombre de contexto de texto**.
1. Seleccione el botón **Guardar**.
1. Para evaluar el solucionador con el objeto de contexto simulado, elija **Run Test (Ejecutar prueba)**.
Veamos un ejemplo más práctico. Imagine que tiene una aplicación que almacena un tipo de GraphQL llamado `Dog`, que genera automáticamente un identificador para los objetos y los almacena en Amazon DynamoDB. También desea escribir algunos valores tomándolos de los argumentos de una mutación de GraphQL y permitir que solo determinados usuarios vean la respuesta. En el siguiente fragmento de código se muestra el aspecto que podría tener el esquema:
```
type Dog {
breed: String
color: String
}
type Mutation {
addDog(firstname: String, age: Int): Dog
}
```
Puedes escribir una AWS AppSync función y añadirla a tu `addDog` resolución para gestionar la mutación. Para probar AWS AppSync la función, puede rellenar un objeto de contexto, como en el siguiente ejemplo. Se incluyen argumentos del cliente como `name` y `age`, así como un `username` rellenado en el objeto `identity`:
```
{
"arguments" : {
"firstname": "Shaggy",
"age": 4
},
"source" : {},
"result" : {
"breed" : "Miniature Schnauzer",
"color" : "black_grey"
},
"identity": {
"sub" : "uuid",
"issuer" : " https://cognito-idp.{region}.amazonaws.com/{userPoolId}",
"username" : "Nadia",
"claims" : { },
"sourceIp" :[ "x.x.x.x" ],
"defaultAuthStrategy" : "ALLOW"
}
}
```
Puedes probar la AWS AppSync función con el siguiente código:
```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({ id: util.autoId() }),
attributeValues: util.dynamodb.toMapValues(ctx.args),
};
}
export function response(ctx) {
if (ctx.identity.username === 'Nadia') {
console.log("This request is allowed")
return ctx.result;
}
util.unauthorized();
}
```
El controlador de solicitudes y respuestas evaluado tiene los datos de su objeto de contexto de prueba y el valor generado de `util.autoId()`. Además, si cambia el `username` por un valor distinto de `Nadia`, no se devolverán resultados, porque la comprobación de autorización daría error. Para obtener más información acerca del control de acceso preciso, consulte [Casos de uso de autorizaciones](security-authorization-use-cases.md#aws-appsync-security-authorization-use-cases).
### Probando los controladores de solicitudes y respuestas con AWS AppSync APIs
Puede usar el comando de API `EvaluateCode` para probar el código de forma remota con datos simulados. Para empezar a usar el comando, asegúrese de haber añadido el permiso `appsync:evaluateMappingCode` a su política. Por ejemplo:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "appsync:evaluateCode",
"Resource": "arn:aws:appsync:us-east-1:111122223333:*"
}
]
}
```
------
Puede aprovechar el comando utilizando la tecla [AWS CLI](https://aws.amazon.com/cli/)o [AWS SDKs](https://aws.amazon.com/tools/). Por ejemplo, tome el `Dog` esquema y sus controladores de solicitudes y respuestas de AWS AppSync funciones de la sección anterior. Con la CLI de la estación local, guarde el código en un archivo denominado `code.js` y, a continuación, guarde el objeto `context` en un archivo denominado `context.json`. Ejecute el siguiente comando desde el intérprete de comandos:
```
$ aws appsync evaluate-code \
--code file://code.js \
--function response \
--context file://context.json \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0
```
La respuesta contiene un `evaluationResult` que incluye la carga útil devuelta por el controlador. También contiene un objeto `logs` que incluye la lista de registros generados por el controlador durante la evaluación. Esto facilita la depuración de la ejecución de código y la consulta de información sobre la evaluación como ayuda para solucionar problemas. Por ejemplo:
```
{
"evaluationResult": "{\"breed\":\"Miniature Schnauzer\",\"color\":\"black_grey\"}",
"logs": [
"INFO - code.js:13:5: \"This request is allowed\""
]
}
```
El `evaluationResult` se puede analizar como JSON, lo que da como resultado:
```
{
"breed": "Miniature Schnauzer",
"color": "black_grey"
}
```
Cuando se utiliza el SDK, puede incorporar fácilmente pruebas de su conjunto de pruebas favorito para validar el comportamiento de los controladores. Recomendamos crear pruebas con el [marco de pruebas Jest](https://jestjs.io/), pero cualquier conjunto de pruebas funciona. En el siguiente fragmento de código se muestra una ejecución de validación hipotética. Tenga en cuenta que esperamos que la respuesta de la evaluación sea un JSON válido, por lo que utilizamos `JSON.parse` para recuperar el JSON de la respuesta de cadena:
```
const AWS = require('aws-sdk')
const fs = require('fs')
const client = new AWS.AppSync({ region: 'us-east-2' })
const runtime = {name:'APPSYNC_JS',runtimeVersion:'1.0.0')
test('request correctly calls DynamoDB', async () => {
const code = fs.readFileSync('./code.js', 'utf8')
const context = fs.readFileSync('./context.json', 'utf8')
const contextJSON = JSON.parse(context)
const response = await client.evaluateCode({ code, context, runtime, function: 'request' }).promise()
const result = JSON.parse(response.evaluationResult)
expect(result.key.id.S).toBeDefined()
expect(result.attributeValues.firstname.S).toEqual(contextJSON.arguments.firstname)
})
```
Esto produce el siguiente resultado:
```
Ran all test suites.
> jest
PASS ./index.test.js
✓ request correctly calls DynamoDB (543 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 totalTime: 1.511 s, estimated 2 s
```
## Depuración de una consulta en tiempo real
No hay nada que sustituya a una end-to-end prueba y un registro para depurar una aplicación de producción. AWS AppSync te permite registrar los errores y los detalles completos de las solicitudes a través de Amazon CloudWatch. Además, puedes usar la AWS AppSync consola para probar las consultas, mutaciones y suscripciones de GraphQL y transmitir en directo los datos de registro de cada solicitud de vuelta al editor de consultas para depurarlos en tiempo real. Para las suscripciones, los registros muestran la información del tiempo de conexión.
Para ello, debes tener habilitados los CloudWatch registros de Amazon con antelación, tal y como se describe en [Supervisión y registro](monitoring.md#aws-appsync-monitoring). A continuación, en la AWS AppSync consola, selecciona la pestaña **Consultas** y, a continuación, introduce una consulta GraphQL válida. En la sección inferior derecha, haga clic y arrastre la ventana **Registros** para abrir la vista de registros. Utilice el icono de flecha de reproducción de la parte superior de la página para ejecutar la consulta de GraphQL. Al cabo de un momento, los registros completos de la solicitud y la respuesta de la operación se enviarán a esta sección y podrá verlos en la consola.
# Configuración y uso de resolutores de canalización en AWS AppSync () JavaScript
AWS AppSync ejecuta resolutores en un campo de GraphQL. En algunos casos, las aplicaciones requieren la ejecución de varias operaciones para resolver un único campo de GraphQL. Con los solucionadores de canalización, los desarrolladores ahora pueden componer operaciones llamadas Funciones y ejecutarlas de forma secuencial. Los solucionadores de canalización son útiles para las aplicaciones que, por ejemplo, requieren realizar una comprobación de autorización antes de recuperar datos para un campo.
[Para obtener más información sobre la arquitectura de un solucionador de JavaScript canalización, consulta la descripción general de los JavaScript resolutores.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html#anatomy-of-a-pipeline-resolver-js)
## Paso 1: creación de un solucionador de canalización
En la AWS AppSync consola, vaya a la página del **esquema**.
Guarde el siguiente esquema:
```
schema {
query: Query
mutation: Mutation
}
type Mutation {
signUp(input: Signup): User
}
type Query {
getUser(id: ID!): User
}
input Signup {
username: String!
email: String!
}
type User {
id: ID!
username: String
email: AWSEmail
}
```
Vamos a conectar un solucionador de canalización al campo **signUp** en el tipo **Mutation (Mutación)**. En el tipo **Mutación** en el lado derecho, elija **Asociar** junto al campo de mutación `signUp`. Configura el solucionador en `pipeline resolver` y el tiempo de ejecución en `APPSYNC_JS` y, a continuación, crea el solucionador.
Nuestro solucionador de canalización inicia sesión a un usuario. Para ello, primero valida la entrada de dirección de correo electrónico y, a continuación, guarda al usuario en el sistema. Vamos a encapsular la validación de correo electrónico dentro de una función **validateEmail** y el guardado del usuario dentro de una función **saveUser**. La función **validateEmail** se ejecuta en primer lugar y, si el correo electrónico es válido, se ejecuta la función **saveUser**.
El flujo de ejecución será como se indica a continuación:
1. Controlador de solicitudes de solucionador Mutation.signUp
1. Función validateEmail
1. Función saveUser
1. Controlador de respuestas de solucionador Mutation.signup
Dado que probablemente reutilizaremos la función **validateEmail** en otros solucionadores de nuestra API, queremos para evitar el acceso a `ctx.args`, ya que estos cambiarán de un campo GraphQL a otro. En su lugar, podemos utilizar `ctx.stash` para almacenar el atributo de correo electrónico desde el argumento de campo de entrada `signUp(input: Signup)`.
Actualice su código de solucionador sustituyendo sus funciones de solicitud y respuesta:
```
export function request(ctx) {
ctx.stash.email = ctx.args.input.email
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
```
Seleccione **Crear** o **Guardar** para actualizar el solucionador.
## Paso 2: creación de una función
En la página del solucionador de canalización, en la sección **Funciones**, haga clic en **Agregar función** y luego en **Crear la función nueva**. También es posible crear funciones sin pasar por la página de resolución; para ello, en la AWS AppSync consola, vaya a la página de **funciones**. Elija el botón **Crear una función**. Vamos a crear una función que comprueba si un mensaje de correo electrónico es válido y proviene de un dominio específico. Si el correo electrónico no es válido, la función genera un error. De lo contrario, reenvía cualquier entrada.
Asegúrese de haber creado un origen de datos del tipo **NINGUNO**. Elija este origen de datos en la lista de **Nombre del origen de datos**. Para el **nombre de a función**, escriba `validateEmail`. En el área de **código de la función**, sobrescriba todo con este fragmento:
```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
const { email } = ctx.stash;
const valid = util.matches(
'^[a-zA-Z0-9_.+-]+@(?:(?:[a-zA-Z0-9-]+\.)?[a-zA-Z]+\.)?(myvaliddomain)\.com',
email
);
if (!valid) {
util.error(`"${email}" is not a valid email.`);
}
return { payload: { email } };
}
export function response(ctx) {
return ctx.result;
}
```
Revise la información indicada y, a continuación, seleccione **Crear**. Acabamos de crear nuestra función **validateEmail**. Repita estos pasos para crear la función **SaveUser** con el siguiente código (para simplificar, utilizamos un origen de datos **NINGUNO** y simulamos que el usuario se ha guardado en el sistema después de ejecutar la función):
```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
return ctx.prev.result;
}
export function response(ctx) {
ctx.result.id = util.autoId();
return ctx.result;
}
```
Acabamos de crear la función **saveUser**.
## Paso 3: adición de una función a un solucionador de canalización
Nuestras funciones deberían haberse agregado automáticamente al solucionador de canalización que acabamos de crear. Si este no es el caso, o si ha creado las funciones a través de la página **Funciones**, puede volver a hacer clic en **Agregar función** en la página `signUp` del solucionador para asociarlas. Agregue las funciones **validateEmail** y **saveUser** al solucionador. La función **validateEmail** se debe colocar antes de la función **saveUser**. A medida que agrega más funciones, puede utilizar las opciones **mover hacia arriba** y **mover hacia abajo** para reorganizar el orden de ejecución de las funciones. Revise sus cambios y, a continuación, elija **Guardar**.
## Paso 4: ejecución de una consulta
En la AWS AppSync consola, vaya a la página de **consultas**. En el explorador, asegúrese de utilizar la mutación. Si no es así, seleccione `Mutation` en la lista desplegable y, a continuación, elija `+`. Escriba la siguiente consulta:
```
mutation {
signUp(input: {email: "nadia@myvaliddomain.com", username: "nadia"}) {
id
username
}
}
```
Debería devolver algo parecido a esto:
```
{
"data": {
"signUp": {
"id": "256b6cc2-4694-46f4-a55e-8cb14cc5d7fc",
"username": "nadia"
}
}
}
```
Hemos registrado correctamente nuestro usuario y validado el correo electrónico de entrada utilizando un solucionador de canalización.
# Creación de consultas básicas (VTL)
**nota**
Ahora admitimos de forma básica el tiempo de ejecución APPSYNC\$1JS y su documentación. Considere la opción de utilizar el tiempo de ejecución APPSYNC\$1JS y sus guías [aquí](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html).
Los solucionadores de GraphQL conectan los campos de un esquema de tipo a un origen de datos. Los resolutores son el mecanismo mediante el cual se tramitan las solicitudes. AWS AppSync pueden crear y conectar automáticamente resolutores a partir de un esquema o crear un esquema y conectar resolutores desde una tabla existente sin necesidad de escribir ningún código.
Resolvers que se AWS AppSync utilizan JavaScript para convertir una expresión de GraphQL en un formato que pueda utilizar la fuente de datos. Como alternativa, las plantillas de asignación se pueden escribir en [Apache Velocity Template Language (VTL)](https://velocity.apache.org/engine/2.0/vtl-reference.html) para convertir una expresión de GraphQL en un formato que el origen de datos pueda utilizar.
En esta sección se mostrará cómo configurar los solucionadores mediante VTL. [En la guía de programación de plantillas de mapeo de Resolver encontrará una guía de programación tipo tutorial introductorio para escribir [resolutores, y en la referencia contextual de la plantilla de mapeo](resolver-mapping-template-reference-programming-guide.md#aws-appsync-resolver-mapping-template-reference-programming-guide) de Resolver encontrará utilidades auxiliares para su uso durante la programación.](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference) AWS AppSync también incluye flujos de prueba y depuración integrados que puedes usar cuando editas o creas desde cero. Para obtener más información, consulte la sección sobre la [prueba y depuración de solucionadores](test-debug-resolvers.md#aws-appsync-test-debug-resolvers).
Recomendamos seguir esta guía antes de intentar utilizar alguno de los tutoriales mencionados anteriormente.
En esta sección, veremos cómo crear un solucionador, añadir un solucionador para mutaciones y usar configuraciones avanzadas.
## Cree su primer solucionador
Siguiendo los ejemplos de las secciones anteriores, el primer paso es crear un solucionador para su tipo de `Query`.
------
#### [ Console ]
1. [Inicia sesión en la consola Consola de administración de AWS y ábrelaAppSync .](https://console.aws.amazon.com/appsync/)
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Esquema**.
1. En la parte derecha de la página, hay una ventana llamada **Solucionadores**. Este cuadro contiene una lista de los tipos y campos definidos en la ventana **Esquema** del lado izquierdo de la página. Puede asociar solucionadores a los campos. Por ejemplo, en el tipo de **Consulta**, seleccione **Asociar** junto al campo `getTodos`.
1. En la página **Crear un solucionador**, elija el origen de datos que creó en la guía [Asociar un origen de datos](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html). En la ventana **Configurar plantillas de asignación**, puede elegir las plantillas de asignación genéricas de solicitud y respuesta utilizando la lista desplegable de la derecha o escribir las suyas propias.
**nota**
El emparejamiento de una plantilla de asignación de solicitudes con una plantilla de asignación de respuestas se denomina solucionador unitario. Los solucionadores unitarios suelen estar diseñados para realizar operaciones rutinarias; recomendamos usarlos solo para operaciones singulares con un número reducido de orígenes de datos. Para operaciones más complejas, recomendamos utilizar solucionadores de canalización, que pueden ejecutar varias operaciones con diversos orígenes de datos de forma secuencial.
Para obtener más información acerca de la diferencia entre las plantillas de asignación de solicitudes y respuestas, consulte [Solucionadores unitarios](https://docs.aws.amazon.com//appsync/latest/devguide/resolver-mapping-template-reference-overview.html#unit-resolvers).
Para obtener más información sobre el uso de solucionadores de canalización, consulte [Solucionadores de canalización](pipeline-resolvers.md#aws-appsync-pipeline-resolvers).
1. Para los casos de uso más comunes, la AWS AppSync consola tiene plantillas integradas que puedes usar para obtener elementos de fuentes de datos (por ejemplo, todas las consultas de elementos, búsquedas individuales, etc.). Por ejemplo en la versión sencilla del esquema que se da en la sección [Diseño del esquema](designing-your-schema.md#aws-appsync-designing-your-schema) en la que `getTodos` no tenía paginación, la plantilla de asignación de solicitudes para enumerar elementos es la siguiente:
```
{
"version" : "2017-02-28",
"operation" : "Scan"
}
```
1. Siempre se necesita una plantilla de asignación de respuestas para complementar la solicitud. La consola ofrece un valor predeterminado con el siguiente valor de acceso directo para las listas:
```
$util.toJson($ctx.result.items)
```
En este ejemplo, el objeto `context` (con el alias `$ctx`) para las listas de elementos tiene la forma `$context.result.items`. Si su operación de GraphQL devuelve un solo elemento, sería `$context.result`. AWS AppSync proporciona funciones auxiliares para operaciones comunes como la función `$util.toJson` enumerada anteriormente, para dar formato a las respuestas correctamente. Para ver una lista completa de funciones, consulte [Referencia de utilidad de la plantilla de asignación de solucionadores](resolver-util-reference.md#aws-appsync-resolver-mapping-template-util-reference).
1. Seleccione **Guardar solucionador**.
------
#### [ API ]
1. Cree un objeto de resolución llamando a la API de [https://docs.aws.amazon.com/appsync/latest/APIReference/API_CreateResolver.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_CreateResolver.html).
1. Puede modificar los campos del solucionador llamando a la API de [https://docs.aws.amazon.com/appsync/latest/APIReference/API_UpdateResolver.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_UpdateResolver.html).
------
#### [ CLI ]
1. Cree un solucionador ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html).
Deberá escribir 6 parámetros para este comando concreto:
1. El `api-id` de su API.
1. El `type-name` del tipo que quiere modificar en su esquema. En el ejemplo de la consola, esto era `Query`.
1. El `field-name` del campo que quiere modificar en su tipo. En el ejemplo de la consola, esto era `getTodos`.
1. El `data-source-name` del origen de datos que creó en la guía [Asociar un origen de datos](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html).
1. La `request-mapping-template`, que es el cuerpo de la solicitud. En el ejemplo de la consola, esto era:
```
{
"version" : "2017-02-28",
"operation" : "Scan"
}
```
1. La `response-mapping-template`, que es el cuerpo de la respuesta. En el ejemplo de la consola, esto era:
```
$util.toJson($ctx.result.items)
```
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-resolver --api-id abcdefghijklmnopqrstuvwxyz --type-name Query --field-name getTodos --data-source-name TodoTable --request-mapping-template "{ "version" : "2017-02-28", "operation" : "Scan", }" --response-mapping-template ""$"util.toJson("$"ctx.result.items)"
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"resolver": {
"kind": "UNIT",
"dataSourceName": "TodoTable",
"requestMappingTemplate": "{ version : 2017-02-28, operation : Scan, }",
"resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Query/resolvers/getTodos",
"typeName": "Query",
"fieldName": "getTodos",
"responseMappingTemplate": "$util.toJson($ctx.result.items)"
}
}
```
1. Para modificar las plantillas de and/or mapeo de campos de un solucionador, ejecute el [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-resolver.html)comando.
Con la excepción del parámetro `api-id`, los parámetros utilizados en el comando `create-resolver` se sobrescribirán con los nuevos valores del comando `update-resolver`.
------
## Adición de un solucionador para mutaciones
El siguiente paso es crear un solucionador para su tipo de `Mutation`.
------
#### [ Console ]
1. Inicie sesión en la [AppSync consola Consola de administración de AWS y ábrala](https://console.aws.amazon.com/appsync/).
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Esquema**.
1. En el tipo de **Mutación**, seleccione **Asociar** junto al campo `addTodo`.
1. En la página **Crear un solucionador**, elija el origen de datos que creó en la guía [Asociar un origen de datos](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html).
1. En la ventana **Configurar plantillas de asignación**, modifique la plantilla de solicitud, ya que se trata de una mutación en la que se añade un elemento nuevo a DynamoDB. Use la siguiente plantilla de asignación de solicitud.
```
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : $util.dynamodb.toDynamoDBJson($ctx.args.id)
},
"attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```
1. AWS AppSync convierte automáticamente los argumentos definidos en el `addTodo` campo del esquema de GraphQL en operaciones de DynamoDB. En el ejemplo anterior se almacenan registros en DynamoDB mediante una clave de `id`, que se transfiere desde el argumento de mutación como `$ctx.args.id`. Todos los demás campos que transfiera se mapearán automáticamente en atributos de DynamoDB con `$util.dynamodb.toMapValuesJson($ctx.args)`.
Para este solucionador, use la siguiente plantilla de mapeo de respuesta:
```
$util.toJson($ctx.result)
```
AWS AppSync también admite flujos de trabajo de prueba y depuración para la edición de resoluciones. Puede usar un objeto `context` simulado para ver el valor transformado de la plantilla antes de la invocación. De forma opcional, puede ver la ejecución de la solicitud completa en un origen de datos de forma interactiva cuando ejecute una consulta. Para obtener más información, consulte las secciones sobre [prueba y depuración de solucionadores](test-debug-resolvers.md#aws-appsync-test-debug-resolvers) y sobre [monitorización y registro](monitoring.md#aws-appsync-monitoring).
1. Seleccione **Guardar solucionador**.
------
#### [ API ]
También puede hacerlo APIs utilizando los comandos de la sección [Cree su primera resolución](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) y los detalles de los parámetros de esta sección.
------
#### [ CLI ]
También puede hacer esto en la CLI utilizando los comandos de la sección [Cree su primer solucionador](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) y los detalles de los parámetros de esta sección.
------
En este momento, si no usa los solucionadores avanzados, puede empezar a utilizar su API de GraphQL tal como se indica en [Uso de la API](using-your-api.md#aws-appsync-using-your-api).
## Solucionadores avanzados
Si está siguiendo la sección avanzada y crea un esquema de ejemplo en [Diseño del esquema](designing-your-schema.md#aws-appsync-designing-your-schema) para realizar un análisis paginado, utilice la siguiente plantilla de solicitud para el campo `getTodos`:
```
{
"version" : "2017-02-28",
"operation" : "Scan",
"limit": $util.defaultIfNull(${ctx.args.limit}, 20),
"nextToken": $util.toJson($util.defaultIfNullOrBlank($ctx.args.nextToken, null))
}
```
En este caso de uso de paginación el mapeo de la respuesta es algo más que un acceso directo, ya que debe contener tanto el *cursor* (de modo que el cliente sepa en qué página comenzar a continuación) como el conjunto de resultados. La plantilla de mapeo es la siguiente:
```
{
"todos": $util.toJson($context.result.items),
"nextToken": $util.toJson($context.result.nextToken)
}
```
Los campos de la plantilla de mapeo de respuesta anterior tienen que coincidir con los campos definidos en su tipo `TodoConnection`.
En el caso de las relaciones en las que tiene una tabla `Comments` y usted está solucionando el campo de comentarios del tipo `Todo` (que devuelve un tipo de `[Comment]`), puede utilizar una plantilla de asignación que ejecute una consulta en la segunda tabla. Para ello, ya debe haber creado un origen de datos para la tabla `Comments` tal como se indica en [Asociar un origen de datos](attaching-a-data-source.md#aws-appsync-getting-started-build-a-schema-from-scratch).
**nota**
Usamos una operación de consulta en otra tabla solo con fines ilustrativos. También podría usar otra operación realizada en DynamoDB en su lugar. Además, puede extraer los datos de otra fuente de datos, como AWS Lambda Amazon OpenSearch Service, ya que la relación está controlada por su esquema de GraphQL.
------
#### [ Console ]
1. Inicia sesión en la [AppSync consola Consola de administración de AWS](https://console.aws.amazon.com/appsync/) y ábrela.
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Esquema**.
1. En el tipo **Todo**, seleccione **Asociar** junto al campo `comments`.
1. En la página **Crear solucionador**, elija el origen de datos de la tabla **Comentarios**. El nombre predeterminado de la tabla **Comentarios** en las guías de inicio rápido es `AppSyncCommentTable`, pero puede variar en función del nombre que le haya dado.
1. Añada el siguiente fragmento de código a su plantilla de asignación de solicitud:
```
{
"version": "2017-02-28",
"operation": "Query",
"index": "todoid-index",
"query": {
"expression": "todoid = :todoid",
"expressionValues": {
":todoid": {
"S": $util.toJson($context.source.id)
}
}
}
}
```
1. `context.source` hace referencia al objeto principal del campo actual que se está resolviendo. En este ejemplo, `source.id` hace referencia al objeto `Todo` individual, que se usa a continuación para la expresión de consulta.
Puede utilizar la plantilla de mapeo de respuesta de acceso directo de la siguiente manera:
```
$util.toJson($ctx.result.items)
```
1. Seleccione **Guardar solucionador**.
1. Por último, en la página **Esquema**, asocie un solucionador al campo `addComment` y especifique el origen de datos para la tabla `Comments`. La plantilla de mapeo de solicitud en este caso es un elemento `PutItem` sencillo con el elemento `todoid` específico en el que se realiza el comentario como argumento, pero usa la utilidad `$utils.autoId()` para crear una clave de ordenación única para el comentario de la siguiente manera:
```
{
"version": "2017-02-28",
"operation": "PutItem",
"key": {
"todoid": { "S": $util.toJson($context.arguments.todoid) },
"commentid": { "S": "$util.autoId()" }
},
"attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```
Utilice una plantilla de respuesta de acceso directo de la siguiente manera:
```
$util.toJson($ctx.result)
```
------
#### [ API ]
También puedes hacerlo APIs utilizando los comandos de la sección [Crea tu primera resolución](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) y los detalles de los parámetros de esta sección.
------
#### [ CLI ]
También puede hacer esto en la CLI utilizando los comandos de la sección [Cree su primer solucionador](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) y los detalles de los parámetros de esta sección.
------
# Desactivación de las plantillas de mapeo de VTL con solucionadores de Lambda directos (VTL)
**nota**
Ahora admitimos de forma básica el tiempo de ejecución APPSYNC\$1JS y su documentación. Considere la opción de utilizar el tiempo de ejecución APPSYNC\$1JS y sus guías [aquí](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html).
Con los resolutores Lambda directos, puede evitar el uso de plantillas de mapeo de VTL al utilizar fuentes de datos. AWS Lambda AWS AppSync puede proporcionar una carga útil predeterminada a la función de Lambda, así como una traducción predeterminada de la respuesta de una función de Lambda a un tipo de GraphQL. Puedes elegir entre proporcionar una plantilla de solicitud, una plantilla de respuesta o ninguna de las dos, y la AWS AppSync gestionarás en consecuencia.
Para obtener más información sobre la carga útil de solicitud predeterminada y la traducción de respuestas que AWS AppSync proporciona, consulte la referencia de resolución de [Direct Lambda](resolver-mapping-template-reference-lambda.md#direct-lambda-resolvers). Para obtener más información sobre la configuración de una fuente de AWS Lambda datos y la configuración de una política de confianza de IAM, consulte [Adjuntar](attaching-a-data-source.md) una fuente de datos.
## Configurar solucionadores de Lambda directos
En las secciones siguientes, se muestra cómo asociar orígenes de datos de Lambda y cómo añadir solucionadores de Lambda a los campos.
### Añadir un origen de datos de Lambda
Para poder activar los solucionadores de Lambda directos, debe añadir un origen de datos de Lambda.
------
#### [ Console ]
1. [Inicie sesión en la consola Consola de administración de AWS y ábrala. AppSync](https://console.aws.amazon.com/appsync/)
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Origen de datos**.
1. Elija **Crear origen de datos**.
1. En **Nombre de origen de datos**, introduzca un nombre para el origen de datos (por ejemplo, **myFunction**).
1. En **Tipo de origen de datos**, elija **AWS Lambda Ninguno**.
1. En **Región**, elija la región apropiada.
1. En **ARN de la función**, elija la función de Lambda en la lista desplegable. Puede buscar el nombre de la función o introducir manualmente el ARN de la función que desee utilizar.
1. Cree un nuevo rol de IAM (recomendado) o elija un rol existente que tenga el permiso de IAM `lambda:invokeFunction`. Los roles existentes necesitan una política de confianza, tal y como se explica en la sección [Asociar un origen de datos](attaching-a-data-source.md).
El siguiente es un ejemplo de política de IAM que tiene los permisos necesarios para llevar a cabo operaciones en el recurso:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "lambda:invokeFunction" ],
"Resource": [
"arn:aws:lambda:us-west-2:123456789012:function:myFunction",
"arn:aws:lambda:us-west-2:123456789012:function:myFunction:*"
]
}
]
}
```
------
1. Pulse el botón **Crear**.
------
#### [ CLI ]
1. Cree un origen de datos ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-data-source.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-data-source.html).
Deberá escribir 4 parámetros para este comando concreto:
1. El `api-id` de su API.
1. El `name` de origen de datos. En el ejemplo de la consola, este es el **nombre del origen de datos**.
1. El `type` de origen de datos. En el ejemplo de la consola, se trata de una **función AWS Lambda **.
1. El `lambda-config`, que es el **ARN de la función** el ejemplo de la consola.
**nota**
Hay otros parámetros, como `Region`, que deben configurarse pero que normalmente se utilizarán de forma predeterminada en los valores de configuración de la CLI.
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name myFunction --type AWS_LAMBDA --lambda-config lambdaFunctionArn=arn:aws:lambda:us-west-2:102847592837:function:appsync-lambda-example
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"dataSource": {
"dataSourceArn": "arn:aws:appsync:us-west-2:102847592837:apis/abcdefghijklmnopqrstuvwxyz/datasources/myFunction",
"type": "AWS_LAMBDA",
"name": "myFunction",
"lambdaConfig": {
"lambdaFunctionArn": "arn:aws:lambda:us-west-2:102847592837:function:appsync-lambda-example"
}
}
}
```
1. Para modificar los atributos de un origen de datos, ejecute el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-data-source.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-data-source.html).
Con la excepción del parámetro `api-id`, los parámetros utilizados en el comando `create-data-source` se sobrescribirán con los nuevos valores del comando `update-data-source`.
------
### Activar los solucionadores de Lambda directos
Tras crear una fuente de datos Lambda y configurar la función de IAM adecuada para poder AWS AppSync invocar la función, puede vincularla a una función de resolución o de canalización.
------
#### [ Console ]
1. [Inicie sesión en la consola Consola de administración de AWS y ábrala. AppSync](https://console.aws.amazon.com/appsync/)
1. En el **APIs panel de control**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Esquema**.
1. En la ventana **Solucionadores**, elija un campo u operación y, a continuación, seleccione el botón **Asociar**.
1. En la página **Crear nuevo solucionador**, elija la función de Lambda en la lista desplegable.
1. Para aprovechar los solucionadores de Lambda directos, confirme que las plantillas de asignación de solicitud y respuesta estén deshabilitadas en la sección **Configurar plantillas de asignación**.
1. Pulse el botón **Guardar solucionador**.
------
#### [ CLI ]
+ Cree un solucionador ejecutando el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html).
Deberá escribir 6 parámetros para este comando concreto:
1. El `api-id` de su API.
1. El `type-name` del tipo de su esquema.
1. El `field-name` del campo de su esquema.
1. El `data-source-name` o el nombre de su función de Lambda.
1. La `request-mapping-template`, que es el cuerpo de la solicitud. En el ejemplo de la consola, esto estaba deshabilitado:
```
" "
```
1. La `response-mapping-template`, que es el cuerpo de la respuesta. En el ejemplo de la consola, esto también estaba deshabilitado:
```
" "
```
Un comando de ejemplo puede tener este aspecto:
```
aws appsync create-resolver --api-id abcdefghijklmnopqrstuvwxyz --type-name Subscription --field-name onCreateTodo --data-source-name LambdaTest --request-mapping-template " " --response-mapping-template " "
```
Aparecerá un resultado en la CLI. A continuación se muestra un ejemplo:
```
{
"resolver": {
"resolverArn": "arn:aws:appsync:us-west-2:102847592837:apis/abcdefghijklmnopqrstuvwxyz/types/Subscription/resolvers/onCreateTodo",
"typeName": "Subscription",
"kind": "UNIT",
"fieldName": "onCreateTodo",
"dataSourceName": "LambdaTest"
}
}
```
------
Al deshabilitar las plantillas de asignación, en AWS AppSync se producen varios comportamientos adicionales:
+ Al deshabilitar una plantilla de mapeo, indica AWS AppSync que acepta las traducciones de datos predeterminadas especificadas en la referencia de resolución de Direct [Lambda](resolver-mapping-template-reference-lambda.md#direct-lambda-resolvers).
+ Al deshabilitar la plantilla de asignación de solicitudes, el origen de datos de Lambda recibirá una carga compuesta por todo el objeto [Context](resolver-context-reference.md).
+ Al deshabilitar la plantilla de asignación de respuestas, el resultado de la invocación de Lambda se traducirá en función de la versión de la plantilla de asignación de solicitudes o de si la plantilla de asignación de solicitudes también está deshabilitada.
# Prueba y depuración de resolutores en AWS AppSync (VTL)
**nota**
Ahora admitimos de forma básica el tiempo de ejecución APPSYNC\$1JS y su documentación. Considere la opción de utilizar el tiempo de ejecución APPSYNC\$1JS y sus guías [aquí](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html).
AWS AppSync ejecuta resolutores en un campo GraphQL contra una fuente de datos. Como se describe en [Resolver mapping template overview](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview), los solucionadores se comunican con los orígenes de datos mediante un lenguaje de plantillas. Esto permite personalizar el comportamiento y aplicar lógica y condiciones antes y después de comunicarse con el origen de datos. Encontrará una guía de programación introductoria similar a un tutorial para escribir solucionadores en [Resolver mapping template programming guide](resolver-mapping-template-reference-programming-guide.md#aws-appsync-resolver-mapping-template-reference-programming-guide).
Para ayudar a los desarrolladores a escribir, probar y depurar estos resolutores, la AWS AppSync consola también proporciona herramientas para crear una solicitud y una respuesta de GraphQL con datos simulados para cada solucionador de campo individual. Además, puedes realizar consultas, mutaciones y suscripciones en la AWS AppSync consola y ver un registro detallado de Amazon CloudWatch de toda la solicitud. Esto incluye los resultados del origen de datos.
## Prueba con datos simulados
Cuando se invoca a un solucionador de GraphQL, este contiene un objeto `context` que incluye información sobre la solicitud. Por ejemplo, contiene los argumentos de un cliente, información de identidad y datos del campo principal de GraphQL. También contiene los resultados del origen de datos, que puede usar en la plantilla de respuesta. Si desea más información acerca de esta estructura y las utilidades auxiliares disponibles para programar, consulte la [Referencia del contexto de las plantillas de mapeo de solucionador](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference).
Al escribir o editar un solucionador, puede pasar un objeto *simulado* o *de contexto de prueba* al editor de la consola. Esto le permite ver cómo se evalúan la plantillas de solicitud y de respuesta sin que se utilice en realidad ningún origen de datos. Por ejemplo, puede transferir un argumento `firstname: Shaggy` de prueba y ver cómo se evalúa cuando utiliza `$ctx.args.firstname` en el código de la plantilla. También puede probar la evaluación de cualquier utilidad auxiliar, como `$util.autoId()` o `util.time.nowISO8601()`.
### Prueba de solucionadores
En este ejemplo, se utilizará la AWS AppSync consola para probar los resolutores.
1. Inicie sesión en la [AppSyncconsola Consola de administración de AWS](https://console.aws.amazon.com/appsync/) y ábrala.
1. En el **APIs panel**, elige tu API de GraphQL.
1. En la **barra lateral**, seleccione **Esquema**.
1. Si aún no lo ha hecho, en el tipo y junto al campo, seleccione **Asociar** para añadir su solucionador.
Para obtener más información acerca de cómo crear un solucionador completo, consulte [Configuring resolvers](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html).
De lo contrario, seleccione el solucionador que ya esté en el campo.
1. En la parte superior de la página **Editar el solucionador**, seleccione **Seleccionar contexto de prueba** y, a continuación, **Crear nuevo contexto**.
1. Seleccione un objeto de contexto de ejemplo o rellene el JSON manualmente en la ventana **Contexto de ejecución** que aparece a continuación.
1. Introduzca un **Nombre de contexto de texto**.
1. Seleccione el botón **Guardar**.
1. En la parte superior de la página **Editar solucionador**, seleccione **Ejecutar prueba**.
Veamos un ejemplo más práctico. Imagine que tiene una aplicación que almacena un tipo de GraphQL llamado `Dog`, que genera automáticamente un identificador para los objetos y los almacena en Amazon DynamoDB. También desea escribir algunos valores tomándolos de los argumentos de una mutación de GraphQL y permitir que solo determinados usuarios vean la respuesta. El esquema podría tener el siguiente aspecto:
```
type Dog {
breed: String
color: String
}
type Mutation {
addDog(firstname: String, age: Int): Dog
}
```
Al añadir un solucionador para la mutación `addDog`, puede rellenar un objeto de contexto como el que aparece en el ejemplo a continuación. Se incluyen argumentos del cliente como `name` y `age`, así como un `username` rellenado en el objeto `identity`:
```
{
"arguments" : {
"firstname": "Shaggy",
"age": 4
},
"source" : {},
"result" : {
"breed" : "Miniature Schnauzer",
"color" : "black_grey"
},
"identity": {
"sub" : "uuid",
"issuer" : " https://cognito-idp.{region}.amazonaws.com/{userPoolId}",
"username" : "Nadia",
"claims" : { },
"sourceIp" :[ "x.x.x.x" ],
"defaultAuthStrategy" : "ALLOW"
}
}
```
Puede probarlo utilizando las siguientes plantillas de mapeo de solicitud y de respuesta:
**Plantilla de solicitud**
```
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : { "S" : "$util.autoId()" }
},
"attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```
**Plantilla de respuesta**
```
#if ($context.identity.username == "Nadia")
$util.toJson($ctx.result)
#else
$util.unauthorized()
#end
```
La plantilla evaluada tiene los datos del objeto de contexto de prueba y el valor generado por `$util.autoId()`. Además, si cambia el `username` por un valor distinto de `Nadia`, no se devolverán resultados, porque la comprobación de autorización daría error. Para obtener más información acerca del control de acceso preciso, consulte [Casos de uso de autorizaciones](security-authorization-use-cases.md#aws-appsync-security-authorization-use-cases).
### Probando plantillas de mapeo con AWS AppSync APIs
Puede usar el comando de API `EvaluateMappingTemplate` para probar las plantillas de mapeo de forma remota con datos simulados. Para empezar a usar el comando, asegúrese de haber añadido el permiso `appsync:evaluateMappingTemplate` a su política. Por ejemplo:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "appsync:evaluateMappingTemplate",
"Resource": "arn:aws:appsync:us-east-1:111122223333:*"
}
]
}
```
------
Puede aprovechar el comando mediante la tecla [AWS CLI](https://aws.amazon.com/cli/)o [AWS SDKs](https://aws.amazon.com/tools/). Por ejemplo, tome el `Dog` esquema y sus plantillas de request/response mapeo de la sección anterior. Con la CLI de la estación local, guarde la plantilla de solicitudes en un archivo denominado `request.vtl` y, a continuación, guarde el objeto `context` en un archivo denominado `context.json`. Ejecute el siguiente comando desde el intérprete de comandos:
```
aws appsync evaluate-mapping-template --template file://request.vtl --context file://context.json
```
El comando devuelve la siguiente respuesta:
```
{
"evaluationResult": "{\n \"version\" : \"2017-02-28\",\n \"operation\" : \"PutItem\",\n \"key\" : {\n \"id\" : { \"S\" : \"afcb4c85-49f8-40de-8f2b-248949176456\" }\n },\n \"attributeValues\" : {\"firstname\":{\"S\":\"Shaggy\"},\"age\":{\"N\":4}}\n}\n"
}
```
`evaluationResult`Contiene los resultados de la prueba de la plantilla proporcionada con el `context` proporcionado. También puede probar sus plantillas con AWS SDKs. Este es un ejemplo del uso del AWS SDK para la JavaScript versión 2:
```
const AWS = require('aws-sdk')
const client = new AWS.AppSync({ region: 'us-east-2' })
const template = fs.readFileSync('./request.vtl', 'utf8')
const context = fs.readFileSync('./context.json', 'utf8')
client
.evaluateMappingTemplate({ template, context })
.promise()
.then((data) => console.log(data))
```
Cuando se utiliza el SDK, puede incorporar fácilmente pruebas de su conjunto de pruebas favorito para validar el comportamiento de la plantilla. Recomendamos crear pruebas con el [marco de pruebas Jest](https://jestjs.io/), pero cualquier conjunto de pruebas funciona. En el siguiente fragmento de código se muestra una ejecución de validación hipotética. Tenga en cuenta que esperamos que la respuesta de la evaluación sea un JSON válido, por lo que utilizamos `JSON.parse` para recuperar el JSON de la respuesta de cadena:
```
const AWS = require('aws-sdk')
const fs = require('fs')
const client = new AWS.AppSync({ region: 'us-east-2' })
test('request correctly calls DynamoDB', async () => {
const template = fs.readFileSync('./request.vtl', 'utf8')
const context = fs.readFileSync('./context.json', 'utf8')
const contextJSON = JSON.parse(context)
const response = await client.evaluateMappingTemplate({ template, context }).promise()
const result = JSON.parse(response.evaluationResult)
expect(result.key.id.S).toBeDefined()
expect(result.attributeValues.firstname.S).toEqual(contextJSON.arguments.firstname)
})
```
Esto produce el siguiente resultado:
```
Ran all test suites.
> jest
PASS ./index.test.js
✓ request correctly calls DynamoDB (543 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 1.511 s, estimated 2 s
```
## Depuración de una consulta en tiempo real
No hay nada que sustituya a una end-to-end prueba y un registro para depurar una aplicación de producción. AWS AppSync te permite registrar los errores y los detalles completos de las solicitudes a través de Amazon CloudWatch. Además, puedes usar la AWS AppSync consola para probar las consultas, mutaciones y suscripciones de GraphQL y transmitir en directo los datos de registro de cada solicitud de vuelta al editor de consultas para depurarlos en tiempo real. Para las suscripciones, los registros muestran la información del tiempo de conexión.
Para ello, debes tener habilitados los CloudWatch registros de Amazon con antelación, tal y como se describe en [Supervisión y registro](monitoring.md#aws-appsync-monitoring). A continuación, en la AWS AppSync consola, selecciona la pestaña **Consultas** y, a continuación, introduce una consulta GraphQL válida. En la sección inferior derecha, haga clic y arrastre la ventana **Registros** para abrir la vista de registros. Utilice el icono de flecha de reproducción de la parte superior de la página para ejecutar la consulta de GraphQL. Al cabo de unos momentos, los registros completos de la solicitud y la respuesta de la operación se enviarán a esta sección y podrá verlos en la consola.
# Configuración y uso de solucionadores de canalización en AWS AppSync (VTL)
**nota**
Ahora admitimos de forma básica el tiempo de ejecución APPSYNC\$1JS y su documentación. Considere la opción de utilizar el tiempo de ejecución APPSYNC\$1JS y sus guías [aquí](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html).
AWS AppSync ejecuta resolutores en un campo GraphQL. En algunos casos, las aplicaciones requieren la ejecución de varias operaciones para resolver un único campo de GraphQL. Con los solucionadores de canalización, los desarrolladores ahora pueden componer operaciones llamadas Funciones y ejecutarlas de forma secuencial. Los solucionadores de canalización son útiles para las aplicaciones que, por ejemplo, requieren realizar una comprobación de autorización antes de recuperar datos para un campo.
Un solucionador de canalización se compone de una plantilla de mapeo **Antes**, una plantilla de mapeo **Después** y una lista de funciones. Cada función tiene una plantilla de mapeo de **solicitudes** y **respuestas** que ejecuta con un origen de datos. Puesto que un solucionador de canalización delega la ejecución a una lista de funciones, no está vinculado a ningún origen de datos. Las funciones y los solucionadores de unidad son primitivos que ejecutan operaciones frente a los orígenes de datos. Para obtener más información, consulte [Información general sobre las plantillas de mapeo de solucionador](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview).
## Paso 1: creación de un solucionador de canalización
**En la AWS AppSync consola, ve a la página del esquema.**
Guarde el siguiente esquema:
```
schema {
query: Query
mutation: Mutation
}
type Mutation {
signUp(input: Signup): User
}
type Query {
getUser(id: ID!): User
}
input Signup {
username: String!
email: String!
}
type User {
id: ID!
username: String
email: AWSEmail
}
```
Vamos a conectar un solucionador de canalización al campo **signUp** en el tipo **Mutation (Mutación)**. En el tipo **Mutación** en el lado derecho, elija **Asociar** junto al campo de mutación `signUp`. En la página de creación de solucionadores, haga clic en **Acciones** y, a continuación, en **Actualizar el tiempo de ejecución**. Elija `Pipeline Resolver`, luego `VTL` y, a continuación, **Actualizar**. Ahora, la página ahora debería mostrar tres secciones: un área de texto **Plantilla de mapeo Antes**, una sección **Funciones** y un área de texto **Plantilla de mapeo Después**.
Nuestro solucionador de canalización inicia sesión a un usuario. Para ello, primero valida la entrada de dirección de correo electrónico y, a continuación, guarda al usuario en el sistema. Vamos a encapsular la validación de correo electrónico dentro de una función **validateEmail** y el guardado del usuario dentro de una función **saveUser**. La función **validateEmail** se ejecuta en primer lugar y, si el correo electrónico es válido, se ejecuta la función **saveUser**.
El flujo de ejecución será como se indica a continuación:
1. Plantilla de mapeo de solicitud de solucionador Mutation.signUp
1. Función validateEmail
1. Función saveUser
1. Plantilla de mapeo de respuesta de solucionador Mutation.signUp
Dado que probablemente reutilizaremos la función **validateEmail** en otros solucionadores de nuestra API, queremos para evitar el acceso a `$ctx.args`, ya que estos cambiarán de un campo GraphQL a otro. En su lugar, podemos utilizar `$ctx.stash` para almacenar el atributo de correo electrónico desde el argumento de campo de entrada `signUp(input: Signup)`.
Plantilla de mapeo **ANTES**:
```
## store email input field into a generic email key
$util.qr($ctx.stash.put("email", $ctx.args.input.email))
{}
```
La consola ofrece un acceso directo predeterminado de plantilla de mapeo **DESPUÉS** que vamos a utilizar:
```
$util.toJson($ctx.result)
```
Seleccione **Crear** o **Guardar** para actualizar el solucionador.
## Paso 2: creación de una función
En la página del solucionador de canalización, en la sección **Funciones**, haga clic en **Agregar función** y luego en **Crear la función nueva**. También es posible crear funciones sin pasar por la página de resolución; para ello, en la AWS AppSync consola, vaya a la página de **funciones**. Elija el botón **Crear una función**. Vamos a crear una función que comprueba si un mensaje de correo electrónico es válido y proviene de un dominio específico. Si el correo electrónico no es válido, la función genera un error. De lo contrario, reenvía cualquier entrada.
En la nueva página de funciones, seleccione **Acciones** y, a continuación, **Actualizar tiempo de ejecución**. Elija `VTL` y, a continuación, **Actualizar**. Asegúrese de haber creado un origen de datos del tipo **NINGUNO**. Elija este origen de datos en la lista de **Nombre del origen de datos**. Para el **nombre de función**, introduzca `validateEmail`. En el área de **código de la función**, sobrescriba todo con este fragmento:
```
#set($valid = $util.matches("^[a-zA-Z0-9_.+-]+@(?:(?:[a-zA-Z0-9-]+\.)?[a-zA-Z]+\.)?(myvaliddomain)\.com", $ctx.stash.email))
#if (!$valid)
$util.error("$ctx.stash.email is not a valid email.")
#end
{
"payload": { "email": $util.toJson(${ctx.stash.email}) }
}
```
Péguelo en la plantilla de mapeo de respuestas:
```
$util.toJson($ctx.result)
```
Revise sus modificaciones y, a continuación, elija **Crear**. Acabamos de crear nuestra función **validateEmail**. Repita estos pasos para crear la función **SaveUser** con las siguientes plantillas de mapeo de solicitudes y respuestas (para simplificar, utilizamos un origen de datos **NINGUNO** y simulamos que el usuario se ha guardado en el sistema después de ejecutar la función):
Plantilla de mapeo de solicitudes:
```
## $ctx.prev.result contains the signup input values. We could have also
## used $ctx.args.input.
{
"payload": $util.toJson($ctx.prev.result)
}
```
Plantilla de mapeo de respuestas:
```
## an id is required so let's add a unique random identifier to the output
$util.qr($ctx.result.put("id", $util.autoId()))
$util.toJson($ctx.result)
```
Acabamos de crear la función **saveUser**.
## Paso 3: adición de una función a un solucionador de canalización
Nuestras funciones deberían haberse agregado automáticamente al solucionador de canalización que acabamos de crear. Si este no es el caso, o si ha creado las funciones a través de la página **Funciones**, puede volver a hacer clic en **Agregar función** en la página del solucionador para asociarlas. Agregue las funciones **validateEmail** y **saveUser** al solucionador. La función **validateEmail** se debe colocar antes de la función **saveUser**. A medida que agrega más funciones, puede utilizar las opciones **mover hacia arriba** y **mover hacia abajo** para reorganizar el orden de ejecución de las funciones. Revise sus cambios y, a continuación, elija **Guardar**.
## Paso 4: Ejecución de una consulta
En la AWS AppSync consola, vaya a la página de **consultas**. En el explorador, asegúrese de utilizar la mutación. Si no es así, seleccione `Mutation` en la lista desplegable y, a continuación, elija `+`. Escriba la siguiente consulta:
```
mutation {
signUp(input: {
email: "nadia@myvaliddomain.com"
username: "nadia"
}) {
id
email
}
}
```
Debería devolver algo parecido a esto:
```
{
"data": {
"signUp": {
"id": "256b6cc2-4694-46f4-a55e-8cb14cc5d7fc",
"email": "nadia@myvaliddomain.com"
}
}
}
```
Hemos registrado correctamente nuestro usuario y validado el correo electrónico de entrada utilizando un solucionador de canalización. Para seguir un tutorial más completo centrado en los solucionadores de canalización, puede ir al [tutorial de solucionadores de canalización](tutorial-pipeline-resolvers.md#aws-appsync-tutorial-pipeline-resolvers)
# Uso de una AWS AppSync API con el AWS CDK
**sugerencia**
[Antes de usar la CDK, te recomendamos que consultes la [documentación oficial](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html) de la CDK junto con AWS AppSync su referencia.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)
También recomendamos asegurarse de que las instalaciones de la [CLI de AWS](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) y [NPM](https://docs.npmjs.com/) funcionan en el sistema.
En esta sección, vamos a crear una aplicación de CDK sencilla que pueda añadir y obtener elementos de una tabla de DynamoDB. Se trata de un ejemplo de inicio rápido en el que se utiliza parte del código de las secciones [Diseñar un esquema](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html), [Adjuntar una fuente de datos](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) y [Configurar](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html) resolutores (). JavaScript
## Configuración de un proyecto de CDK
**aviso**
Es posible que estos pasos no sean completamente precisos en función del entorno. Suponemos que su sistema tiene instaladas las utilidades necesarias, una forma de interactuar con AWS los servicios y las configuraciones adecuadas.
El primer paso es instalar el AWS CDK. En su CLI, puede introducir el comando siguiente:
```
npm install -g aws-cdk
```
A continuación, debe crear un directorio del proyecto y, luego, navegar hasta él. Un ejemplo de un conjunto de comandos para crear un directorio y navegar a él es:
```
mkdir example-cdk-app
cd example-cdk-app
```
A continuación, debe crear una aplicación. Nuestro servicio utiliza TypeScript principalmente. Ejecute el siguiente comando en el directorio de su proyecto:
```
cdk init app --language typescript
```
Al hacerlo, se instalará una aplicación CDK junto con sus archivos de inicialización:
![\[Terminal output showing Git repository initialization and npm install completion.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-init-app-example.png)
La estructura de proyecto puede tener un aspecto similar al siguiente:
![\[Project directory structure showing folders and files for an example CDK app.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-init-directories.png)
Se dará cuenta de que tenemos varios directorios importantes:
+ `bin`: el archivo bin inicial creará la aplicación. No trataremos este tema en esta guía.
+ `lib`: el directorio lib contiene los archivos de pila. Los archivos de pila se podrían comparar a unidades de ejecución individuales. Las construcciones estarán dentro de nuestros archivos de pila. Básicamente, se trata de recursos para un servicio que se activará CloudFormation cuando se despliegue la aplicación. Aquí es donde se realizará la mayor parte de nuestra codificación.
+ `node_modules`: este directorio lo creó NPM y contiene todas las dependencias de paquetes que instaló mediante el comando `npm`.
Nuestro archivo de pila inicial puede contener algo como esto:
```
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
// import * as sqs from 'aws-cdk-lib/aws-sqs';
export class ExampleCdkAppStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// The code that defines your stack goes here
// example resource
// const queue = new sqs.Queue(this, 'ExampleCdkAppQueue', {
// visibilityTimeout: cdk.Duration.seconds(300)
// });
}
}
```
Este es el código reutilizable para crear una pila en nuestra aplicación. La mayor parte del código de este ejemplo se incluirá en el ámbito de esta clase.
Para comprobar que el archivo de pila está en la aplicación, en el directorio de la aplicación, ejecute el siguiente comando en el terminal:
```
cdk ls
```
Debería aparecer una lista de sus pilas. Si no es así, es posible que tenga que volver a realizar los pasos o consultar la documentación oficial para obtener ayuda.
Si quiere compilar los cambios de código antes de implementarlos, siempre puede ejecutar el siguiente comando en el terminal:
```
npm run build
```
Y, para ver los cambios antes de la implementación:
```
cdk diff
```
Antes de añadir nuestro código al archivo de pila, vamos a realizar un arranque. El arranque nos permite aprovisionar recursos para el CDK antes de que se implemente la aplicación. Puede encontrar más información sobre este proceso [aquí](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html). El comando para crear un arranque es:
```
cdk bootstrap aws://ACCOUNT-NUMBER/REGION
```
**sugerencia**
Este paso requiere varios permisos de IAM en su cuenta. Se denegará el arranque si no los tiene. Si esto ocurre, es posible que tenga que eliminar los recursos incompletos que ha causado el arranque, como el bucket de S3 que genera.
El arranque generará varios recursos. El mensaje final tendrá el siguiente aspecto:
![\[Terminal output showing successful bootstrapping of an AWS environment.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-init-bootstrap-final.png)
Esto se hace una vez por cuenta y región, por lo que no tendrá que hacerlo con frecuencia. Los principales recursos del bootstrap son la CloudFormation pila y el bucket de Amazon S3.
El bucket de Amazon S3 se utiliza para almacenar archivos y roles de IAM que conceden los permisos necesarios para realizar las implementaciones. Los recursos necesarios se definen en una CloudFormation pila, denominada pila bootstrap, que suele tener ese nombre. `CDKToolkit` Como cualquier CloudFormation pila, aparece en la CloudFormation consola una vez desplegada:
![\[CDKToolkit stack with CREATE_COMPLETE status in CloudFormation console.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-init-bootstrap-cfn-console.png)
Lo mismo puede decirse del bucket:
![\[S3 bucket details showing name, region, access settings, and creation date.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-init-bootstrap-bucket-console.png)
Para importar los servicios que necesitamos en nuestro archivo de pila, podemos usar el siguiente comando:
```
npm install aws-cdk-lib # V2 command
```
**sugerencia**
Si tiene problemas con la V2, puede instalar las bibliotecas individuales mediante los comandos de la V1:
```
npm install @aws-cdk/aws-appsync @aws-cdk/aws-dynamodb
```
No recomendamos esta opción porque la V1 está en desuso.
## Implementación de un proyecto de CDK: esquema
Ahora podemos empezar a implementar nuestro código. En primer lugar, debemos crear nuestro esquema. Simplemente puede crear un archivo `.graphql` en su aplicación:
```
mkdir schema
touch schema.graphql
```
En nuestro ejemplo, incluimos un directorio de nivel superior llamado `schema` que contiene nuestro `schema.graphql`:
![\[File structure showing a schema folder containing schema.graphql file.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-schema-directory.png)
Dentro de nuestro esquema, vamos a incluir un ejemplo sencillo:
```
input CreatePostInput {
title: String
content: String
}
type Post {
id: ID!
title: String
content: String
}
type Mutation {
createPost(input: CreatePostInput!): Post
}
type Query {
getPost: [Post]
}
```
De vuelta a nuestro archivo de pila, debemos asegurarnos de que estén definidas las siguientes directivas de importación:
```
import * as cdk from 'aws-cdk-lib';
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { Construct } from 'constructs';
```
Dentro de la clase, añadiremos código para crear nuestra API de GraphQL y conectarla a nuestro archivo `schema.graphql`:
```
export class ExampleCdkAppStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// makes a GraphQL API
const api = new appsync.GraphqlApi(this, 'post-apis', {
name: 'api-to-process-posts',
schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
});
}
}
```
También añadiremos código para imprimir la URL de GraphQL, la clave de API y la región:
```
export class ExampleCdkAppStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// Makes a GraphQL API construct
const api = new appsync.GraphqlApi(this, 'post-apis', {
name: 'api-to-process-posts',
schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
});
// Prints out URL
new cdk.CfnOutput(this, "GraphQLAPIURL", {
value: api.graphqlUrl
});
// Prints out the AppSync GraphQL API key to the terminal
new cdk.CfnOutput(this, "GraphQLAPIKey", {
value: api.apiKey || ''
});
// Prints out the stack region to the terminal
new cdk.CfnOutput(this, "Stack Region", {
value: this.region
});
}
}
```
En este punto, volveremos a implementar nuestra aplicación:
```
cdk deploy
```
El resultado es el siguiente:
![\[Deployment output showing ExampleCdkAppStack details, including GraphQL API URL and stack region.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-schema.png)
Parece que nuestro ejemplo fue exitoso, pero revisemos la AWS AppSync consola para confirmarlo:
![\[GraphQL interface showing successful API request with response data displayed.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-schema-result-1.png)
Parece que nuestra API se ha creado. Ahora, comprobaremos el esquema asociado a la API:
![\[GraphQL schema defining CreatePostInput, Post type, Mutation, and Query operations.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-schema-result-2.png)
Esto parece coincidir con nuestro código de esquema, por lo que se ha realizado correctamente. Otra forma de confirmarlo desde el punto de vista de los metadatos es observar la CloudFormation pila:
![\[CloudFormation stack showing ExampleCdkAppStack update complete and CDKToolkit creation complete.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-schema-result-3.png)
Cuando implementamos nuestra aplicación CDK, esta activa CloudFormation recursos, como el bootstrap. Cada pila de nuestra aplicación se mapea 1:1 con una CloudFormation pila. Si vuelve al código de la pila, verá que el nombre de la pila se ha tomado del nombre de la clase`ExampleCdkAppStack`. Puede ver los recursos que creó, que también se ajustan a nuestras convenciones de nomenclatura, en nuestra construcción de la API de GraphQL:
![\[Expanded view of post-apis resource showing Schema, DefaultApiKey, and CDKMetadata.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-schema-result-4.png)
## Implementación de un proyecto de CDK: origen de datos
A continuación, debemos añadir nuestro origen de datos. En nuestro ejemplo, se utilizará una tabla de DynamoDB. Dentro de la clase de pila, añadiremos código para crear una tabla nueva:
```
export class ExampleCdkAppStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// Makes a GraphQL API construct
const api = new appsync.GraphqlApi(this, 'post-apis', {
name: 'api-to-process-posts',
schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
});
//creates a DDB table
const add_ddb_table = new dynamodb.Table(this, 'posts-table', {
partitionKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
});
// Prints out URL
new cdk.CfnOutput(this, "GraphQLAPIURL", {
value: api.graphqlUrl
});
// Prints out the AppSync GraphQL API key to the terminal
new cdk.CfnOutput(this, "GraphQLAPIKey", {
value: api.apiKey || ''
});
// Prints out the stack region to the terminal
new cdk.CfnOutput(this, "Stack Region", {
value: this.region
});
}
}
```
Llegados a este punto, volvamos a implementarla:
```
cdk deploy
```
Deberíamos comprobar la consola de DynamoDB para ver nuestra nueva tabla:
![\[DynamoDB console showing ExampleCdkAppStack-poststable as Active with Provisioned capacity.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-ddb-result-1.png)
El nombre de nuestra pila es correcto y el nombre de la tabla coincide con nuestro código. Si volvemos a comprobar nuestra CloudFormation pila, ahora veremos la nueva tabla:
![\[Expanded view of a logical ID in CloudFormation showing post-apis, posts-table, and CDKMetadata.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-ddb-result-2.png)
## Implementación de un proyecto de CDK: solucionador
En este ejemplo, se utilizarán dos solucionadores: uno para consultar la tabla y otro para añadirle elementos. Como utilizamos solucionadores de canalizaciones, tendremos que declarar dos solucionadores de canalizaciones con una función en cada uno. En la consulta, añadiremos el siguiente código:
```
export class ExampleCdkAppStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// Makes a GraphQL API construct
const api = new appsync.GraphqlApi(this, 'post-apis', {
name: 'api-to-process-posts',
schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
});
//creates a DDB table
const add_ddb_table = new dynamodb.Table(this, 'posts-table', {
partitionKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
});
// Creates a function for query
const add_func = new appsync.AppsyncFunction(this, 'func-get-post', {
name: 'get_posts_func_1',
api,
dataSource: api.addDynamoDbDataSource('table-for-posts', 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,
});
// Creates a function for mutation
const add_func_2 = new appsync.AppsyncFunction(this, 'func-add-post', {
name: 'add_posts_func_1',
api,
dataSource: api.addDynamoDbDataSource('table-for-posts-2', add_ddb_table),
code: appsync.Code.fromInline(`
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({id: util.autoId()}),
attributeValues: util.dynamodb.toMapValues(ctx.args.input),
};
}
export function response(ctx) {
return ctx.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
});
// Adds a pipeline resolver with the get function
new appsync.Resolver(this, 'pipeline-resolver-get-posts', {
api,
typeName: 'Query',
fieldName: 'getPost',
code: appsync.Code.fromInline(`
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
pipelineConfig: [add_func],
});
// Adds a pipeline resolver with the create function
new appsync.Resolver(this, 'pipeline-resolver-create-posts', {
api,
typeName: 'Mutation',
fieldName: 'createPost',
code: appsync.Code.fromInline(`
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
pipelineConfig: [add_func_2],
});
// Prints out URL
new cdk.CfnOutput(this, "GraphQLAPIURL", {
value: api.graphqlUrl
});
// Prints out the AppSync GraphQL API key to the terminal
new cdk.CfnOutput(this, "GraphQLAPIKey", {
value: api.apiKey || ''
});
// Prints out the stack region to the terminal
new cdk.CfnOutput(this, "Stack Region", {
value: this.region
});
}
}
```
En este fragmento, añadimos un solucionador de canalizaciones llamado `pipeline-resolver-create-posts` con una función llamada `func-add-post` asociada. Este es el código que añadirá `Posts` a la tabla. El otro solucionador de canalizaciones se ha denominado `pipeline-resolver-get-posts`, con una función llamada `func-get-post` que recupera `Posts` añadidos a la tabla.
Implementaremos esto para añadirlo al AWS AppSync servicio:
```
cdk deploy
```
Comprobemos la AWS AppSync consola para ver si estaban conectadas a nuestra API GraphQL:
![\[GraphQL API schema showing mutation and query fields with Pipeline resolvers.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-1.png)
Parece correcto. En el código, estos dos solucionadores estaban conectados a la API de GraphQL que creamos (indicada por el valor de accesorios `api` presente tanto en los solucionadores como en las funciones). En la API de GraphQL, los campos a los que asociamos nuestros solucionadores también estaban especificados en los accesorios (definidos por `typename` y los accesorios `fieldname` de cada solucionador).
Veamos si el contenido de los solucionadores es correcto empezando por `pipeline-resolver-get-posts`:
![\[Code snippet showing request and response functions in a resolver, with an arrow pointing to them.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-2.png)
Los controladores de antes y después coinciden con nuestro valor de accesorios `code`. También podemos ver una función llamada `add_posts_func_1`, que coincide con el nombre de la función que asociamos en el solucionador.
Veamos el contenido del código de esa función:
![\[Function code showing request and response methods for a PutItem operation.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-3.png)
Esto coincide con los accesorios `code` de la función `add_posts_func_1`. Nuestra consulta se ha cargado correctamente, así que revisemos la consulta:
![\[Resolver code with request and response functions, and a get_posts_func_1 function listed below.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-4.png)
También coinciden con el código. Si nos fijamos en `get_posts_func_1`:
![\[Code snippet showing two exported functions: request returning 'Scan' operation and response returning items.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-5.png)
Todo parece estar en su sitio. Para confirmarlo desde el punto de vista de los metadatos, podemos volver a revisar nuestra pila en CloudFormation :
![\[List of logical IDs for AWS resources including API, table, functions, and pipelines.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-6.png)
Ahora, necesitamos probar este código realizando algunas solicitudes.
## Implementación de un proyecto de CDK: solicitudes
Para probar nuestra aplicación en la AWS AppSync consola, hicimos una consulta y una mutación:
![\[GraphQL code snippet showing a query to get post details and a mutation to create a post.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-request-1.png)
`MyMutation` contiene una operación `createPost` con los argumentos `1970-01-01T12:30:00.000Z` y `first post`. Devuelve los `date` y `title` que hemos introducido, así como el valor `id` generado automáticamente. Al ejecutar la mutación, se obtiene el resultado:
```
{
"data": {
"createPost": {
"date": "1970-01-01T12:30:00.000Z",
"id": "4dc1c2dd-0aa3-4055-9eca-7c140062ada2",
"title": "first post"
}
}
}
```
Si comprobamos rápidamente la tabla de DynamoDB, podemos ver nuestra entrada en la tabla cuando la escaneamos:
![\[DynamoDB table entry showing id, date, and title fields for a single item.\]](http://docs.aws.amazon.com/es_es/appsync/latest/devguide/images/cdk-code-request-2.png)
Al volver a la AWS AppSync consola, si ejecutamos la consulta para recuperarlo`Post`, obtenemos el siguiente resultado:
```
{
"data": {
"getPost": [
{
"id": "9f62c4dd-49d5-48d5-b835-143284c72fe0",
"date": "1970-01-01T12:30:00.000Z",
"title": "first post"
}
]
}
}
```