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

Mesclando APIs em AWS AppSync

À medida que o uso do GraphQL se expande dentro de uma organização, podem surgir concessões entre a facilidade de uso da API e a velocidade de desenvolvimento da API. Por um lado, as organizações adotam AWS AppSync o GraphQL para simplificar o desenvolvimento de aplicativos. Isso oferece aos desenvolvedores uma API flexível que eles podem usar para acessar, manipular e combinar com segurança dados de um ou mais domínios de dados com uma única chamada de rede. Por outro lado, as equipes de uma organização que são responsáveis pelos diferentes domínios de dados combinados em um único endpoint da API GraphQL podem querer a capacidade de criar, gerenciar e implantar atualizações de API independentes umas das outras. Isso aumenta suas velocidades de desenvolvimento.

Para resolver essa tensão, o recurso de APIs AWS AppSync mescladas permite que equipes de diferentes domínios de dados criem e implantem AWS AppSync APIs de forma independente (por exemplo, esquemas, resolvedores, fontes de dados e funções do GraphQL), que podem ser combinadas em uma única API mesclada. Isso dá às organizações a capacidade de manter uma API multidomínio simples de usar, e uma forma de as diferentes equipes que contribuem com essa API poderem fazer atualizações de API de forma rápida e independente.

O diagrama a seguir mostra o fluxo de trabalho da API mesclada:

Usando APIs mescladas, as organizações podem importar os recursos de várias AWS AppSync APIs de origem independentes em um único endpoint de API AWS AppSync mesclada. Para fazer isso, você pode AWS AppSync criar uma lista de AWS AppSync APIs de origem e, em seguida, mesclar todos os metadados associados às APIs de origem, incluindo esquema, tipos, fontes de dados, resolvedores e funções, em uma nova API mesclada. AWS AppSync

Durante as mesclagens, existe a possibilidade de ocorrer um conflito de mesclagem devido a inconsistências no conteúdo dos dados da API de origem, como conflitos de nomenclatura de tipos ao combinar vários esquemas. Para casos de uso simples em que nenhuma definição nas APIs de origem entra em conflito, não há necessidade de modificar os esquemas da API de origem. A API mesclada resultante simplesmente importa todos os tipos, resolvedores, fontes de dados e funções das APIs de origem AWS AppSync originais. Para casos de uso complexos em que surgem conflitos, users/teams eles terão que resolvê-los por vários meios. AWS AppSync fornece aos usuários várias ferramentas e exemplos que podem reduzir os conflitos de mesclagem.

As mesclagens subsequentes configuradas em AWS AppSync propagarão as alterações feitas nas APIs de origem para a API mesclada associada.

APIs mescladas e federação

Há muitas soluções e padrões na comunidade do GraphQL para combinar esquemas do GraphQL e permitir a colaboração em equipe por meio de um gráfico compartilhado. AWS AppSync As APIs mescladas adotam uma abordagem de tempo de construção para a composição do esquema, em que as APIs de origem são combinadas em uma API mesclada separada. Uma abordagem alternativa é colocar um roteador em camadas em tempo de execução em várias APIs ou subgráficos de origem. Nessa abordagem, o roteador recebe uma solicitação, faz referência a um esquema combinado que ele mantém como metadados, constrói um plano de solicitação e, em seguida, distribui os elementos da solicitação em sua sub-estrutura subjacente. graphs/servers A tabela a seguir compara a abordagem de tempo de construção da API AWS AppSync mesclada com abordagens de tempo de execução baseadas em roteador para a composição do esquema GraphQL:

* As APIs AWS AppSync mescladas só podem ser associadas às APIs de AWS AppSync origem. Se precisar de suporte para composição de esquemas entre AWS AppSync e não AWS AppSync subgráficos, você pode conectar uma ou mais APIs and/or mescladas do AWS AppSync GraphQL a uma solução baseada em roteador. Por exemplo, consulte o blog de referência para adicionar AWS AppSync APIs como um subgráfico usando uma arquitetura baseada em roteador com Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync

Resolução de conflitos de API mesclada

No caso de um conflito de mesclagem, AWS AppSync fornece aos usuários várias ferramentas e exemplos para ajudar a solucionar o (s) problema (s).

Diretivas de esquema de API mescladas

AWS AppSync introduziu várias diretivas do GraphQL que podem ser usadas para reduzir ou resolver conflitos nas APIs de origem:

Para mostrar o esquema de utilitário fornecido pelas diretivas, considere o seguinte exemplo:

Neste exemplo, vamos supor que queremos mesclar duas APIs de origem. Temos dois esquemas que criam e recuperam postagens (por exemplo, seção de comentários ou postagens em mídias sociais). Supondo que os tipos e campos sejam muito semelhantes, há uma grande chance de conflito durante uma operação de mesclagem. Os trechos abaixo mostram os tipos e campos de cada esquema.

O primeiro arquivo, chamado Source1.graphql, é um esquema GraphQL que permite ao usuário criar Posts usando a putPost mutação. Cada Post contém um título e um ID. O ID é usado para referenciar as informações do autor ou do User (e-mail e endereço) e a Message, ou a carga útil (conteúdo). O tipo User é anotado com a tag @canonical.

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post {
    id: ID!
    title: String!
}

type Message {
   id: ID!
   content: String
}

type User @canonical {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
}

O segundo arquivo, chamado Source2.graphql, é um esquema GraphQL que faz coisas muito parecidas com o. Source1.graphql No entanto, observe que os campos de cada tipo são diferentes. Ao mesclar esses dois esquemas, haverá conflitos de mesclagem devido a essas diferenças.

Observe também como Source2.graphql também contém várias diretivas para reduzir esses conflitos. O tipo Post é anotado com uma tag @hidden para se ofuscar durante a operação de mesclagem. O tipo Message é anotado com a tag @renamed para modificar o nome do tipo ChatMessage no caso de um conflito de nomenclatura com outro tipo Message.

# This snippet represents a file called Source2.graphql

type Post @hidden  {
    id: ID!
    title: String!
    internalSecret: String!
}

type Message @renamed(to: "ChatMessage") {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

# Stub user so that we can link the canonical definition from Source1
type User {
   id: ID!
}

type Query {
    getPost(id: ID!): Post
    getMessage(id: ID!): Message @renamed(to: "getChatMessage")
}

Quando a mesclagem ocorrer, o resultado produzirá o arquivo MergedSchema.graphql:

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

# Post from Source2 was hidden so only uses the Source1 definition. 
type Post {
    id: ID!
    title: String!
}

# Renamed from Message to resolve the conflict
type ChatMessage {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

type Message {
   id: ID!
   content: String
}

# Canonical definition from Source1
type User {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
    
    # Renamed from getMessage
    getChatMessage(id: ID!): ChatMessage
}

Várias coisas ocorreram na mesclagem:

Também existe o caso de nenhuma diretiva ser adicionada a um tipo conflitante. Nesse caso, o tipo mesclado incluirá a união de todos os campos de todas as definições de origem desse tipo. Por exemplo, considere o exemplo a seguir:

Esse esquema, chamado Source1.graphql, permite criar e recuperarPosts. A configuração é semelhante à do exemplo anterior, mas com menos informações.

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
}

type Query {
    getPost(id: ID!): Post
}

Esse esquema, chamado Source2.graphql, permite criar e recuperar Reviews (por exemplo, classificação de filmes ou resenhas de restaurantes). Reviewsestão associados ao mesmo valor Post de ID. Juntos, eles contêm o título, o ID da postagem e a mensagem da payload da postagem de avaliação completa.

Ao mesclar, haverá um conflito entre os dois tipos de Post. Como não há anotações para resolver esse problema, o comportamento padrão é realizar uma operação de união nos tipos conflitantes.

# This snippet represents a file called Source2.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
}

type Post  {
    id: ID!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getReview(id: ID!): Review
}

Quando a mesclagem ocorrer, o resultado produzirá o arquivo MergedSchema.graphql:

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getPost(id: ID!): Post
    getReview(id: ID!): Review
}

Várias coisas ocorreram na mesclagem:

Gerenciar resolvedores em tipos compartilhados

No exemplo acima, considere o caso em que Source1.graphql configurou um resolvedor de unidades ativadoQuery.getPost, que usa uma fonte de dados do DynamoDB chamada. PostDatasource Esse resolvedor retornará o id e title de um tipo Post. Agora, considere Source2.graphql configurou um resolvedor de pipelinePost.reviews, que executa duas funções. Function1tem uma fonte None de dados anexada para realizar verificações de autorização personalizadas. Function2tem uma fonte de dados do DynamoDB anexada para consultar a reviews tabela.

query GetPostQuery {
    getPost(id: "1") {
        id,
        title,
        reviews
    }
}

Quando a consulta acima é executada por um cliente no endpoint da API mesclada, o AWS AppSync serviço primeiro executa o resolvedor de unidades para Query.getPost fromSource1, que chama o PostDatasource e retorna os dados do DynamoDB. Em seguida, ele executa o resolvedor de pipeline Post.reviews, no qual Function1 executa a lógica de autorização personalizada e Function2 retorna as avaliações fornecidas ao id encontradas em $context.source. O serviço processa a solicitação como uma única execução do GraphQL, e essa solicitação simples exigirá apenas um único token de solicitação.

Gerenciar conflitos de resolvedor em tipos compartilhados

Considere o seguinte caso Query.getPost em que também implementamos um resolvedor para fornecer vários campos ao mesmo tempo além do resolvedor de campo emSource2. Source1.graphqlpode ter a seguinte aparência:

# This snippet represents a file called Source1.graphql

type Post  {
    id: ID!
    title: String!
    date: AWSDateTime!
}

type Query {
    getPost(id: ID!): Post
}

Source2.graphqlpode ter a seguinte aparência:

# This snippet represents a file called Source2.graphql

type Post  {
  id: ID!
  content: String!
  contentHash: String! 
  author: String! 
}

type Query {
    getPost(id: ID!): Post
}

A tentativa de mesclar esses dois esquemas gerará um erro de mesclagem porque as APIs AWS AppSync mescladas não permitem que vários resolvedores de origem sejam anexados ao mesmo campo. Para resolver esse conflito, você pode implementar um padrão de resolução de campo que exigiria Source2.graphql a adição de um tipo separado que definirá os campos que ele possui do Post tipo. No exemplo a seguir, adicionamos um tipo chamadoPostInfo, que contém os campos de conteúdo e autor que serão resolvidos por Source2.graphql. Source1.graphqlimplementará o resolvedor anexadoQuery.getPost, enquanto agora Source2.graphql anexará um resolvedor Post.postInfo para garantir que todos os dados possam ser recuperados com sucesso:

type Post  {
  id: ID!
  postInfo: PostInfo
}

type PostInfo {
   content: String!
   contentHash: String!
   author: String!
}

type Query {
    getPost(id: ID!): Post
}

Embora a resolução desse conflito exija que os esquemas da API de origem sejam reescritos e, potencialmente, que os clientes alterem suas consultas, a vantagem dessa abordagem é que a propriedade dos resolvedores mesclados permanece clara entre todas as equipes de origem.

Gerenciando a autorização em campos compartilhados

Quando duas ou mais APIs de origem declaram o mesmo campo, a mesclagem combina as diretivas de autorização de cada declaração. Os clientes podem então acessar o campo mesclado por meio de qualquer um desses modos de autorização. Se uma API de origem declarar um campo com @aws_iam e outra declarar o mesmo campo com@aws_api_key, o campo mesclado aceitará qualquer um deles, e um cliente que tenha somente uma chave de API poderá invocá-la.

Para manter a autorização de um campo conforme sua API de origem a define, anote o campo @canonical e declare a diretiva de autorização necessária no próprio campo. No exemplo a seguir, Source1.graphql possui o resolvedor protectedRead e exige autorização do IAM:

# This snippet represents a file called Source1.graphql

type Query {
    protectedRead: String @aws_iam @canonical
}

# This snippet represents a file called Source2.graphql

type Query {
    protectedRead: String @aws_api_key
}

Quando a mesclagem ocorre, a definição de Source1.graphql tem precedência:

# This snippet represents a file called MergedSchema.graphql

type Query {
    protectedRead: String @aws_iam
}

Sem a anotação @canonical, o campo mesclado seria. protectedRead: String @aws_api_key @aws_iam Um cliente que possui somente a chave de API da API mesclada pode então invocá-la.

Se sua API de origem possuir o resolvedor do campo, anote o campo nessa API de origem, pois o resolvedor retorna os dados.

Duas condições se aplicam:

Declare a diretiva de autorização no campo

@canonical preserva o campo conforme declarado. Um campo anotado @canonical sem nenhuma diretiva de autorização própria usa o modo de autorização principal da API de origem, que pode ser mais permissivo do que você pretende.

Anote um campo em apenas uma API de origem

Se duas APIs de origem anotarem o mesmo campo como canonical, a mesclagem falhará com o erro. Multiple subschemas cannot declare the same field as canonical

Aplique @canonical no nível do campo em vez do nível do tipo para restringir a autorização em campos específicos. Isso ainda permite que outras APIs de origem contribuam com campos adicionais para o mesmo tipo. Essa orientação se aplica aos campos em QueryMutation,, e Subscription também aos campos em tipos de objetos.

Se você não quiser que nenhum campo apareça na API mesclada, use @hidden em vez disso. Para obter mais informações, consulte Diretivas de esquema de API mescladas.

Configurar esquemas

Duas partes são responsáveis por configurar os esquemas para criar uma API mesclada:

Como o esquema da API mesclada é criado a partir dos esquemas das APIs de origem associadas, ele é somente para leitura. Isso significa que as alterações no esquema devem ser iniciadas em suas APIs de origem. No AWS AppSync console, você pode alternar entre o esquema mesclado e os esquemas individuais das APIs de origem incluídas na API mesclada usando a lista suspensa acima da janela Esquema.

Configurar modos de autorização

Vários modos de autorização estão disponíveis para proteger sua API mesclada. Para saber mais sobre os modos de autorização em AWS AppSync, consulte Autorização e autenticação.

Os seguintes modos de autorização estão disponíveis para uso com APIs mescladas:

Os modos de autorização de uma API mesclada são configurados pelo proprietário da API mesclada. No momento de uma operação de mesclagem, a API mesclada deve incluir o modo de autorização principal configurado em uma API de origem como seu próprio modo de autorização principal ou como um modo de autorização secundário. Caso contrário, ela será incompatível e a operação de mesclagem falhará devido a um conflito. Ao usar diretivas de autenticação múltipla nas APIs de origem, o processo de mesclagem é capaz de mesclar automaticamente essas diretivas no endpoint unificado. Caso o modo de autorização principal da API de origem não corresponda ao modo de autorização principal da API mesclada, ele adicionará automaticamente essas diretivas de autenticação para garantir que o modo de autorização dos tipos na API de origem seja consistente.

Configurar perfis de execução

Ao criar uma API mesclada, você precisa definir um perfil de serviço. Uma função AWS de serviço é uma função de Gerenciamento de AWS Identidade e Acesso (IAM) usada pelos AWS serviços para realizar tarefas em seu nome.

Nesse contexto, é necessário que sua API mesclada execute resolvedores que acessem dados das fontes de dados configuradas nas APIs de origem. O perfil de serviço necessário para isso é o mergedApiExecutionRole, e ele deve ter acesso explícito para executar solicitações nas APIs de origem incluídas na sua API mesclada por meio da permissão do IAM appsync:SourceGraphQL. Durante a execução de uma solicitação do GraphQL, o AWS AppSync serviço assumirá essa função de serviço e autorizará a função a realizar a appsync:SourceGraphQL ação.

AWS AppSync suporta permitir ou negar essa permissão em campos específicos de nível superior na solicitação, como o modo de autorização do IAM funciona para APIs do IAM. Para campos de nível não superior, AWS AppSync exige que você defina a permissão no próprio ARN da API de origem. Para restringir o acesso a campos específicos que não sejam de nível superior na API mesclada, recomendamos implementar uma lógica personalizada em seu Lambda ou ocultar os campos da API de origem da API mesclada usando a diretiva @hidden. Se você quiser permitir que o perfil execute todas as operações de dados em uma API de origem, adicione a política abaixo. Observe que a primeira entrada de recurso permite acesso a todos os campos de nível superior e a segunda entrada abrange resolvedores secundários que autorizam o próprio atributo da API de origem:

JSON

{
    "Version":"2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/*", 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

Se quiser limitar o acesso somente a um campo específico de nível superior, você pode usar uma política como esta:

JSON

{
    "Version":"2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/types/Query/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

Você também pode usar o assistente de criação da API do AWS AppSync console para gerar uma função de serviço para permitir que sua API mesclada acesse recursos configurados nas APIs de origem que estão na mesma conta da sua API mesclada. Caso suas APIs de origem não estejam na mesma conta da API mesclada, você deve primeiro compartilhar seus recursos usando o AWS Resource Access Manager ()AWS RAM.

Configurando APIs mescladas entre contas usando AWS RAM

Ao criar uma API mesclada, você pode, opcionalmente, associar APIs de origem de outras contas que foram compartilhadas por meio do AWS Resource Access Manager ().AWS RAM AWS RAM ajuda você a compartilhar seus recursos com segurança entre AWS contas, dentro de sua organização ou unidades organizacionais (OUs) e com funções e usuários do IAM.

AWS AppSync integra-se com AWS RAM para oferecer suporte à configuração e ao acesso às APIs de origem em várias contas a partir de uma única API mesclada. AWS RAM permite criar um compartilhamento de recursos ou um contêiner de recursos e os conjuntos de permissões que serão compartilhados para cada um deles. Você pode adicionar AWS AppSync APIs a um compartilhamento de recursos em AWS RAM. Em um compartilhamento de recursos, AWS AppSync fornece três conjuntos de permissões diferentes que podem ser associados a uma AWS AppSync API na RAM:

AWS AppSync também oferece suporte a permissões gerenciadas pelo cliente. Quando uma das permissões AWS gerenciadas fornecidas não funciona, você pode criar sua própria permissão gerenciada pelo cliente. Customer-managed permissões são permissões gerenciadas que você cria e mantém especificando com precisão quais ações podem ser executadas sob quais condições com o uso AWS RAM compartilhado de recursos. AWS AppSync permite que você escolha entre as seguintes ações ao criar sua própria permissão:

Depois de compartilhar adequadamente uma API de origem ou uma API mesclada AWS RAM e, se necessário, o convite de compartilhamento de recursos for aceito, ele ficará visível no AWS AppSync console quando você criar ou atualizar as associações de API de origem em sua API mesclada. Você também pode listar todas as AWS AppSync APIs que foram AWS RAM compartilhadas usando sua conta, independentemente da permissão definida, chamando a ListGraphqlApis operação fornecida AWS AppSync e usando o filtro do OTHER_ACCOUNTS proprietário.

Mesclar

Gerenciar mesclagens

As APIs mescladas têm como objetivo apoiar a colaboração da equipe em um endpoint unificado AWS AppSync . As equipes podem desenvolver de forma independente suas próprias APIs de origem isolada do GraphQL no back-end, enquanto o serviço do AWS AppSync gerencia a integração dos recursos em um único endpoint da API mesclada, a fim de reduzir o atrito na colaboração e diminuir os prazos de desenvolvimento.

Auto-merges

As APIs de origem associadas à sua API AWS AppSync mesclada podem ser configuradas para mesclar automaticamente (mesclar automaticamente) na API mesclada após qualquer alteração ser feita na API de origem. Isso garante que as alterações da API de origem sejam sempre propagadas para o endpoint da API mesclada em segundo plano. Qualquer alteração no esquema da API de origem será atualizada na API mesclada, desde que isso não introduza um conflito de mesclagem com uma definição existente na API mesclada. Se a atualização na API de origem for atualizar um resolvedor, fonte de dados ou função, o atributo importado também será atualizado. Quando um novo conflito é introduzido e não pode ser resolvido automaticamente (resolvido automaticamente), a atualização do esquema da API mesclada é rejeitada devido a um conflito não compatível durante a operação de mesclagem. A mensagem de erro está disponível no console para cada associação de API de origem que tenha um status de MERGE_FAILED. Você também pode inspecionar a mensagem de erro chamando a GetSourceApiAssociation operação para uma determinada associação de API de origem usando o AWS SDK ou usando a AWS CLI da seguinte forma:

aws appsync get-source-api-association --merged-api-identifier <Merged API ARN> --association-id <SourceApiAssociation id>

Isso produzirá um resultado no seguinte formato:

{
    "sourceApiAssociation": {
        "associationId": "<association id>",
        "associationArn": "<association arn>",
        "sourceApiId": "<source api id>",
        "sourceApiArn": "<source api arn>",
        "mergedApiArn": "<merged api arn>",
        "mergedApiId": "<merged api id>",
        "sourceApiAssociationConfig": {
            "mergeType": "MANUAL_MERGE"
        },
        "sourceApiAssociationStatus": "MERGE_FAILED",
        "sourceApiAssociationStatusDetail": "Unable to resolve conflict on object with name title: Merging is not supported for fields with different types."
    }
}

Mesclagens manuais

A configuração padrão para uma API de origem é uma mesclagem manual. Para mesclar as alterações que ocorreram nas APIs de origem desde a última atualização da API mesclada, o proprietário da API de origem pode invocar uma mesclagem manual no AWS AppSync console ou por meio da StartSchemaMerge operação disponível no SDK e na CLI. AWS AWS

Suporte adicional para APIs mescladas

Configurar assinaturas

Diferentemente das abordagens baseadas em roteador para a composição do esquema GraphQL, as APIs AWS AppSync mescladas fornecem suporte integrado para assinaturas do GraphQL. Todas as operações de assinatura definidas em suas APIs de origem associadas serão mescladas e funcionarão automaticamente em sua API mesclada sem modificação. Para saber mais sobre como AWS AppSync oferece suporte a assinaturas por meio de WebSockets conexão sem servidor, consulte os dados. Real-time

Configurar a observabilidade

AWS AppSync As APIs mescladas fornecem registro, monitoramento e métricas integrados via Amazon. CloudWatch AWS AppSync também fornece suporte embutido para rastreamento via AWS X-Ray.

Configurar domínios personalizados

AWS AppSync As APIs mescladas fornecem suporte integrado para o uso de domínios personalizados com o GraphQL e os endpoints da sua API mesclada. Real-time

Configurar o cache

AWS AppSync As APIs mescladas oferecem suporte integrado para armazenar, opcionalmente, respostas em nível de solicitação em nível de and/or resolvedor, bem como compressão de respostas. Para saber mais, consulte Armazenamento em cache e compactação.

Configurar APIs privadas

AWS AppSync As APIs mescladas fornecem suporte integrado para APIs privadas que limitam o acesso ao GraphQL e aos endpoints da sua API mesclada ao tráfego originado de Real-time endpoints VPC que você pode configurar.

Configurar regras de firewall

AWS AppSync As APIs mescladas fornecem suporte integrado para AWS WAF, o que permite que você proteja suas APIs definindo regras de firewall de aplicativos da web.

Configurar logs de auditoria

AWS AppSync As APIs mescladas fornecem suporte integrado para AWS CloudTrail, o que permite configurar e gerenciar registros de auditoria.

Limitações de APIs mescladas

Antes de desenvolver APIs mescladas, observe as seguintes regras:

Considerações sobre a API mesclada

Ao projetar e implementar APIs mescladas, considere o seguinte:

A fusão de várias APIs de origem em um único endpoint pode aumentar o tamanho e a complexidade do esquema e das consultas do GraphQL. À medida que seu esquema mesclado cresce, as consultas podem precisar passar por vários resolvedores para atender a uma única solicitação, o que pode adicionar latência ao tempo geral da solicitação. Por exemplo, uma consulta que acessa campos de várias APIs de origem pode exigir AWS AppSync a execução de resolvedores de cada API de origem em sequência, com cada resolvedor aumentando o tempo total de resposta.

É altamente recomendável que você teste suas APIs mescladas minuciosamente durante o desenvolvimento e sob condições de carga realistas para garantir que elas atendam aos requisitos de seus negócios. Preste atenção específica a:

Considere implementar otimizações de desempenho, como armazenamento em cache, agrupamento de solicitações de fontes de dados e criação de esquemas de API de origem para minimizar o número de execuções de resolvedores necessárias para operações comuns.

Criar APIs mescladas

Para criar uma API mesclada no console