As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Configurando o armazenamento em cache do lado do servidor e a compactação de carga útil no API AWS AppSync
AWS AppSync Os recursos de cache de dados do lado do servidor disponibilizam os dados em um cache na memória de alta velocidade, melhorando a performance e diminuindo a latência. Isso reduz a necessidade de acessar fontes de dados diretamente. O armazenamento em cache está disponível para resolvedores unitários e de pipeline.
AWS AppSync também permite compactar API respostas para que o conteúdo da carga seja carregado e baixado mais rapidamente. Isso reduz potencialmente a pressão sobre suas aplicações e, ao mesmo tempo, reduz potencialmente suas cobranças de transferência de dados. O comportamento de compactação pode ser configurado e definido a seu próprio critério.
Consulte esta seção para obter ajuda na definição do comportamento desejado do armazenamento em cache e da compactação do lado do servidor em seu. AWS AppSync API
Tipos de instância
AWS AppSync hospeda instâncias Amazon ElastiCache (RedisOSS) na mesma AWS conta e AWS região que a sua AWS AppSync API.
Os seguintes tipos de instância ElastiCache (RedisOSS) estão disponíveis:
- pequeno
-
1 vCPU, 1,5 GiBRAM, desempenho de rede baixo a moderado
- medium
-
2 vCPU, 3 GiBRAM, desempenho de rede baixo a moderado
- grande
-
2 vCPU, 12,3 RAM GiB, desempenho de rede de até 10 Gigabit
- xlarge
-
4 vCPU, 25,05 RAM GiB, desempenho de rede de até 10 Gigabit
- 2xlarge
-
8 vCPU, 50,47 GiBRAM, desempenho de rede de até 10 Gigabit
- 4xlarge
-
16 vCPU, 101,38 GiBRAM, desempenho de rede de até 10 Gigabit
- 8xlarge
-
32 vCPU, 203,26 GiBRAM, desempenho de rede de 10 Gigabits (não disponível em todas as regiões)
- 12xlarge
-
48 vCPU, 317,77 GiB, desempenho de rede de 10 RAM Gigabit
nota
Historicamente, você especificou um tipo de instância específico (como t2.medium
). Em julho de 2020, esses tipos de instâncias legados ainda estavam disponíveis, mas seu uso está obsoleto e não é recomendado. Recomendamos que você use os tipos de instância genéricos descritos aqui.
Comportamento de armazenamento em cache
Veja a seguir os comportamentos relacionados ao armazenamento em cache:
- Nenhum
-
Sem armazenamento em cache no lado do servidor.
- Armazenamento em cache de solicitação completa
-
Se os dados não estiverem no cache, eles serão recuperados da fonte de dados e preencherão o cache até a expiração do time to live (TTL). Todas as solicitações subsequentes à sua API são retornadas do cache. Isso significa que as fontes de dados não são contatadas diretamente, a menos que TTL expirem. Nesta configuração, usamos o conteúdo dos mapas
context.arguments
econtext.identity
como chaves de armazenamento em cache. - Armazenamento em cache por resolvedor
-
Com essa configuração, cada resolvedor precisa ser aceito explicitamente para armazenar as respostas em cache. Você pode especificar a TTL e as chaves de cache no resolvedor. As chaves de cache que você pode especificar são os mapas
context.arguments
,context.source
econtext.identity
de nível superior e/ou campos de strings desses mapas. O TTL valor é obrigatório, mas as chaves de cache são opcionais. Se você não especificar nenhuma chave de cache, os padrões serão o conteúdo dos mapascontext.arguments
,context.source
econtext.identity
.Por exemplo, é possível usar as seguintes combinações:
-
context.arguments e context.source
-
context.arguments e context.identity.sub
-
context.arguments.id ou context.arguments. InputType.id
-
context.source.id e context.identity.sub
-
context.identity.claims.username
Quando você especifica somente uma TTL e nenhuma chave de cache, o comportamento do resolvedor é o mesmo do cache completo da solicitação.
-
- Vida útil do cache
-
Ele define por quanto tempo as entradas em cache ficarão armazenadas na memória. O máximo TTL é de 3.600 segundos (1 hora), após os quais as entradas são excluídas automaticamente.
Criptografia de cache
A criptografia de cache é feita de duas formas. Elas são semelhantes às configurações que ElastiCache (RedisOSS) permite. Você pode ativar as configurações de criptografia somente ao ativar o armazenamento em cache pela primeira vez para seu AWS AppSync API.
-
Criptografia em trânsito — As solicitações entre AWS AppSync o cache e as fontes de dados (exceto fontes de HTTP dados inseguras) são criptografadas no nível da rede. Como a criptografia e descriptografia dos dados requerem processamento nos endpoints, a ativação da criptografia em trânsito pode afetar o desempenho.
-
Criptografia em repouso: os dados salvos no disco da memória durante as operações de troca são criptografados na instância do cache. Essa configuração também tem influência no desempenho.
Para invalidar as entradas do cache, você pode fazer uma API chamada de cache de descarga usando o AWS AppSync console ou o AWS Command Line Interface ().AWS CLI
Para obter mais informações, consulte o tipo de ApiCachedados na AWS AppSync API Referência.
Remoção de cache
Ao configurar o cache AWS AppSync do lado do servidor, você pode configurar um máximo. TTL Ele define por quanto tempo as entradas em cache serão armazenadas na memória. Em situações em que você precisa remover entradas específicas do seu cache, você pode usar o utilitário AWS AppSync de evictFromApiCache
extensões na solicitação ou resposta do seu resolvedor. (Por exemplo, os dados em suas fontes de dados mudaram, e agora sua entrada de cache ficou obsoleta.) Para remover um item do cache, você deve saber qual é sua chave. Por esse motivo, se você precisar despejar itens dinamicamente, recomendamos usar o cache por resolvedor e definir explicitamente uma chave para adicionar entradas ao seu cache.
Remover uma entrada de cache
Para remover um item do cache, use o utilitário de extensões evictFromApiCache
. Especifique o nome do tipo e o nome do campo e, em seguida, forneça um objeto de itens de valor-chave para criar a chave da entrada que você deseja remover. No objeto, cada chave representa uma entrada válida do objeto context
que é usada na lista de cachingKey
em cache do resolvedor. Para criar o valor da chave são usados os valores reais. Você deve colocar os itens no objeto seguindo a ordem das chaves de cache na lista em cache de cachingKey
do resolvedor.
Por exemplo, confira o seguinte esquema:
type Note { id: ID! title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note }
Neste exemplo, você pode habilitar o armazenamento em cache por resolvedor e, em seguida, habilitá-lo para a consulta de getNote
. Em seguida, é possível configurar a chave de cache de modo que ela seja [context.arguments.id]
.
Quando você tenta obter umNote
, para criar a chave de cache, AWS AppSync executa uma pesquisa em seu cache do lado do servidor usando o id
argumento da consulta. getNote
Ao atualizar uma Note
, é preciso remover a entrada da nota específica para garantir que a próxima solicitação realize a busca na fonte de dados do back-end. Para isso, crie um manipulador de solicitações.
O exemplo a seguir mostra um modo de lidar com a remoção usando este método:
import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.args.id': ctx.args.id }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result;
Outra opção é tratar da remoção no manipulador de respostas.
Quando a updateNote
mutação é processada, AWS AppSync tenta expulsar a entrada. Se uma entrada for apagada com sucesso, a resposta vai conter um valor de apiCacheEntriesDeleted
no objeto extensions
que mostra quantas entradas foram excluídas:
"extensions": { "apiCacheEntriesDeleted": 1}
Remover uma entrada de cache com base na identidade
Você pode criar chaves de cache com base em diversos valores do objeto context
.
Por exemplo, veja o esquema a seguir, que usa grupos de usuários do Amazon Cognito como modo de autenticação padrão e é apoiado por uma fonte de dados do Amazon DynamoDB:
type Note { id: ID! # a slug; e.g.: "my-first-note-on-graphql" title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note }
Os tipos de objeto Note
são salvos em uma tabela do DynamoDB. A tabela tem uma chave composta que usa o nome de usuário do Amazon Cognito como chave primária e o id
(um slug) da Note
como chave de partição. Esse é um sistema multilocatário que pode hospedar vários usuários e atualizar seus objetos privados Note
, que nunca são compartilhados.
Como esse é um sistema que exige muita leitura, a getNote
consulta é armazenada usando o cache por resolvedor, com a chave de cache composta por [context.identity.username, context.arguments.id]
. Quando a Note
é atualizada, você pode despejar a entrada específica da Note
. Você deve adicionar os componentes no objeto seguindo a ordem em que estão especificados na lista de cachingKeys
do seu resolvedor.
O exemplo a seguir mostra isso.
import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.identity.username, 'ctx.args.id': ctx.args.id, }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result;
Um sistema de back-end também pode atualizar a Note
e remover a entrada. Por exemplo, considere esta mutação:
type Mutation { updateNoteFromBackend(id: ID!, content: String!, username: ID!): Note @aws_iam }
Você pode despejar a entrada, mas adicionar os componentes da chave de cache ao objeto cachingKeys
.
No exemplo a seguir, a remoção ocorre na resposta do resolvedor:
import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export function response(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.args.username, 'ctx.args.id': ctx.args.id, }); return ctx.result; }
Nos casos em que seus dados de back-end foram atualizados externamente AWS AppSync, você pode remover um item do cache chamando uma mutação que usa uma fonte de dados. NONE
Compressão de API respostas
AWS AppSync permite que os clientes solicitem cargas comprimidas. Se solicitadas, API as respostas são compactadas e retornadas em resposta às solicitações que indicam que o conteúdo compactado é preferido. APIAs respostas compactadas carregam mais rápido, o download do conteúdo é mais rápido e suas taxas de transferência de dados também podem ser reduzidas.
nota
A compactação está disponível em todos os novos APIs criados após 1º de junho de 2020.
AWS AppSync comprime objetos com base no melhor esforço. Em casos raros, AWS AppSync pode pular a compressão com base em vários fatores, incluindo a capacidade atual.
AWS AppSync pode compactar tamanhos de payload de consulta GraphQL entre 1.000 e 10.000.000 bytes. Para ativar a compactação, o cliente deve enviar o cabeçalho de Accept-Encoding
com o valor gzip
. A compactação pode ser confirmada ao verificar o valor do cabeçalho Content-Encoding
na resposta (gzip
).
O explorador de consultas no AWS AppSync console define automaticamente o valor do cabeçalho na solicitação por padrão. Se você executar uma consulta com uma resposta grande o suficiente, a compactação poderá ser confirmada usando as ferramentas de desenvolvedor do seu navegador.