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.

Referencia de contexto de las plantillas de mapeo del solucionador de AWS AppSync

AWS AppSync define un conjunto de variables y funciones para trabajar con plantillas de mapeo de solucionador. Esto simplifica las operaciones lógicas realizadas en los datos en GraphQL. En este documento se describen estas funciones y se proporcionan ejemplos para trabajar con plantillas.

Acceso a $context

La variable $context es un mapa que contiene toda la información contextual de la invocación al solucionador. Tiene la estructura siguiente:

{
   "arguments" : { ... },
   "source" : { ... },
   "result" : { ... },
   "identity" : { ... },
   "request" : { ... },
   "info": { ... }
}

Cada campo del mapa $context se define de la siguiente manera:

Campos $context

Identidad

La sección identity contiene información sobre el intermediario. La forma de esta sección depende del tipo de autorización de su API de AWS AppSync.

Para obtener más información sobre las opciones de seguridad de AWS AppSync, consulte Autorización y autenticación.

Cada campo se define de la siguiente manera:

Acceso a los encabezados de solicitud

AWS AppSync permite enviar encabezados personalizados de los clientes y obtener acceso a ellos desde los solucionadores de GraphQL utilizando $context.request.headers. Puede utilizar los valores de encabezado para acciones como insertar datos en un origen de datos o incluso efectuar comprobaciones de autorización. Puede usar uno o varios encabezados de solicitud usando $curl con una clave de API desde la línea de comandos, como se muestra en los siguientes ejemplos:

Ejemplo de encabezado único

Supongamos que establece un encabezado custom con un valor nadia como el siguiente:

curl -XPOST -H "Content-Type:application/graphql" -H "custom:nadia" -H "x-api-key:<API-KEY-VALUE>" -d '{"query":"mutation { createEvent(name: \"demo\", when: \"Next Friday!\", where: \"Here!\") {id name when where description}}"}' https://<ENDPOINT>/graphql

Se puede obtener acceso a este encabezado con $context.request.headers.custom. Por ejemplo, podría encontrarse en la siguiente VTL para DynamoDB:

"custom": $util.dynamodb.toDynamoDBJson($context.request.headers.custom)

Ejemplo de varios encabezados

También puede pasar varios encabezados en una única solicitud y obtener acceso a ellos en la plantilla de mapeo de solucionadores. Por ejemplo, si el encabezado custom se define con dos valores:

curl -XPOST -H "Content-Type:application/graphql" -H "custom:bailey" -H "custom:nadia" -H "x-api-key:<API-KEY-VALUE>" -d '{"query":"mutation { createEvent(name: \"demo\", when: \"Next Friday!\", where: \"Here!\") {id name when where description}}"}' https://<ENDPOINT>/graphql

Puede obtener acceso a ellos como una matriz, por ejemplo $context.request.headers.custom[1].

Acceso al nombre de dominio personalizado de la solicitud

AWS AppSync admite la configuración de un dominio personalizado que puede usar para acceder a sus puntos de conexión de GraphQL y en tiempo real para sus API. Al hacer una solicitud con un nombre de dominio personalizado, puede obtener el nombre de dominio utilizando. $context.request.domainName

Cuando se utiliza el nombre de dominio de punto de conexión predeterminado de GraphQL, el valor es. null

Información

La sección info contiene información sobre la solicitud de GraphQL. Esta sección incluye la siguiente forma:

{
    "fieldName": "string",
    "parentTypeName": "string",
    "variables": { ... },
    "selectionSetList": ["string"],
    "selectionSetGraphQL": "string"
}

Cada campo se define de la siguiente manera:

Por ejemplo, al resolver el campo getPost de la siguiente consulta:

query {
  getPost(id: $postId) {
    postId
    title
    secondTitle: title
    content
    author(id: $authorId) {
      authorId
      name
    }
    secondAuthor(id: "789") {
      authorId
    }
    ... on Post {
      inlineFrag: comments: {
        id
      }
    }
    ... postFrag
  }
}

fragment postFrag on Post {
  postFrag: comments: {
    id
  }
}

La variable $context.info completa que está disponible al procesar una plantilla de mapeo podría ser:

{
  "fieldName": "getPost",
  "parentTypeName": "Query",
  "variables": {
    "postId": "123",
    "authorId": "456"
  },
  "selectionSetList": [
    "postId",
    "title",
    "secondTitle"
    "content",
    "author",
    "author/authorId",
    "author/name",
    "secondAuthor",
    "secondAuthor/authorId",
    "inlineFragComments",
    "inlineFragComments/id",
    "postFragComments",
    "postFragComments/id"
  ],
  "selectionSetGraphQL": "{\n  getPost(id: $postId) {\n    postId\n    title\n    secondTitle: title\n    content\n    author(id: $authorId) {\n      authorId\n      name\n    }\n    secondAuthor(id: \"789\") {\n      authorId\n    }\n    ... on Post {\n      inlineFrag: comments {\n        id\n      }\n    }\n    ... postFrag\n  }\n}"
}

selectionSetList expone solo los campos que pertenecen al tipo actual. Si el tipo actual es una interfaz o una unión, solo se exponen los campos seleccionados que pertenecen a la interfaz. Por ejemplo, en el caso del esquema siguiente:

type Query {
    node(id: ID!): Node
}

interface Node {
    id: ID
}

type Post implements Node {
    id: ID
    title: String
    author: String
}

type Blog implements Node {
    id: ID
    title: String
    category: String
}

Y en la siguiente consulta:

query {
    node(id: "post1") {
        id
        ... on Post {
            title
        }

        ... on Blog {
            title
        }
    }
}

Cuando se llama a $ctx.info.selectionSetList con la resolución del campo Query.node, solo se expone id:

"selectionSetList": [
    "id"
]

Sanear datos entrantes

Las aplicaciones deben sanear datos entrantes que no sean de confianza para evitar que cualquier parte externa dé un uso fuera de lo previsto a una aplicación. Como el $context contiene datos entrantes del usuario en las propiedades como $context.arguments, $context.identity, $context.result, $context.info.variables y $context.request.headers, hay que tener cuidado de sanear sus valores en las plantillas de mapeo.

Dado que las plantillas de asignación representan archivos JSON, el saneamiento de la entrada la toma forma de escapar de caracteres reservados JSON a partir de cadenas que representan las entradas del usuario. Se recomienda usar la utilidad $util.toJson() para escapar caracteres JSON reservados de valores de cadenas sensibles al colocarlos en una plantilla de asignación.

Por ejemplo, en la siguiente plantilla de mapeo de la solicitud de Lambda, como hemos accedido a una cadena de entrada de cliente no segura ($context.arguments.id), la envolvemos con $util.toJson() para evitar que los caracteres JSON no escapados rompan la plantilla JSON.

{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "getPost",
        "postId": $util.toJson($context.arguments.id)
    }
}

A diferencia de la siguiente plantilla de asignación, donde insertamos $context.arguments.id directamente sin sanear. Esto no funciona en cadenas que contienen comillas sin escapar u otros caracteres reservados en JSON, y podrían dejar la plantilla abierta a errores.

## DO NOT DO THIS
{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "getPost",
        "postId": "$context.arguments.id" ## Unsafe! Do not insert $context string values without escaping JSON characters.
    }
}