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 em APIs AWS AppSync À medida que o uso do GraphQL se expande dentro de uma organização, podem surgir compensações entre a API e a velocidade de desenvolvimento da API ease-of-use. 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 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 APIs recurso AWS AppSync Merged permite que equipes de diferentes domínios de dados criem e implantem de forma independente AWS AppSync APIs (por exemplo, esquemas, resolvedores, fontes de dados e funções do GraphQL), que podem então 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: ![\[Diagrama mostrando o fluxo de trabalho da API mesclada com várias fontes APIs sendo combinadas em um único endpoint de API mesclada\]](http://docs.aws.amazon.com/pt_br/appsync/latest/devguide/images/merged-api-workflow.png) Usando o Merged APIs, as organizações podem importar os recursos de várias fontes independentes AWS AppSync APIs em um único endpoint de API AWS AppSync mesclada. Para fazer isso, você AWS AppSync pode criar uma lista de fontes e AWS AppSync APIs, em seguida, mesclar todos os metadados associados à fonte, APIs 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 na fonte está em APIs 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 da fonte original. AWS AppSync APIs Para casos de uso complexos em que surjam conflitos, eles users/teams 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 no AWS AppSync propagarão as alterações feitas na fonte APIs para a API mesclada associada. ## Fusão APIs e federação Há muitas soluções e padrões na comunidade GraphQL para combinar esquemas do GraphQL e permitir a colaboração em equipe por meio de um gráfico compartilhado. AWS AppSync O Merged APIs adota uma abordagem de *tempo de construção* para a composição do esquema, em que APIs as fontes são combinadas em uma API mesclada separada. Uma abordagem alternativa é colocar um roteador em camadas em *tempo de execução* em várias fontes APIs ou subgráficos. 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 seus subgráficos/servidores subjacentes. 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: | | | | | --- |--- |--- | | Recurso | AppSync API mesclada | Soluções baseadas em roteadores | | Subgráficos gerenciados de maneira independente | Sim | Sim | | Subgráficos endereçáveis de forma independente | Sim | Sim | | Composição automatizada do esquema | Sim | Sim | | Detecção automatizada de conflitos | Sim | Sim | | Resolução de conflitos por meio de diretivas de esquema | Sim | Sim | | Servidores de subgráficos compatíveis | AWS AppSync\$1 | Varia | | Complexidade da rede | Uma API única e mesclada significa que não há saltos extras na rede. | A arquitetura multicamada requer planejamento e delegação de consultas, análise e serialização/desserialização de subconsultas e resolvedores de referência em subgráficos para realizar junções. | | Suporte de observabilidade | Monitoramento, registro e rastreamento integrados. Um único servidor de API mesclado significa depuração simplificada. | Build-your-own observabilidade no roteador e em todos os servidores de subgráficos associados. Depuração complexa em sistemas distribuídos. | | Suporte de autorização | Suporte integrado para vários modos de autorização. | Build-your-own regras de autorização. | | Segurança entre contas | Suporte integrado para associações de contas entre AWS nuvens. | Build-your-own modelo de segurança. | | Suporte para assinaturas | Sim | Não | \$1 O AWS AppSync mesclado só APIs pode ser associado à AWS AppSync fonte APIs. Se precisar de suporte para composição de esquemas entre AWS AppSync e sem AWS AppSync subgráficos, você pode conectar um ou mais GraphQL and/or APIs Merged em uma solução AWS AppSync baseada em roteador. [Por exemplo, consulte o blog de referência para adicionar AWS AppSync APIs como subgráfico usando uma arquitetura baseada em roteador com o Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync](https://aws.amazon.com/blogs/mobile/federation-appsync-subgraph/) **Topics** + [Fusão APIs e federação](#merged-api-federation) + [Resolução de conflitos de API mesclada](#merged-api-conflict-resolution) + [Configurar esquemas](#configuring-schemas-merged-api) + [Configurar modos de autorização](#configuring-authorization-merged-api) + [Configurar perfis de execução](#execution-roles-merged-api) + [Configurando contas cruzadas mescladas usando APIs AWS RAM](#cross-account-merged-api) + [Mesclar](#merges) + [Suporte adicional para Merged APIs](#merge-api-additional-support) + [Limitações de APIs mescladas](#merged-api-limits) + [Considerações sobre a API mesclada](#merged-api-considerations) + [Criando mesclado APIs](#creating-merged-api) ## 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 na fonte: APIs + *@canonical*: essa diretiva define a precedência de tipos/campos com nomes e dados semelhantes. Se duas ou mais fontes APIs tiverem o mesmo tipo ou campo do GraphQL, uma delas APIs poderá anotar seu tipo ou campo como *canônico*, o que será priorizado durante a mesclagem. Os conflitos types/fields que não estão anotados com esta diretiva em outra fonte APIs são ignorados quando mesclados. + *@hidden*: Esta diretiva encapsula certos types/fields para removê-los do processo de fusão. As equipes podem querer remover ou ocultar tipos ou operações específicos na API de origem para que somente clientes internos possam acessar dados digitados específicos. Com essa diretiva anexada, os tipos ou campos não são mesclados na API mesclada. + *@renamed*: Essa diretiva altera os nomes de types/fields para reduzir os conflitos de nomenclatura. Há situações em que diferentes APIs têm o mesmo tipo ou nome de campo. No entanto, todos eles precisam estar disponíveis no esquema mesclado. Uma maneira simples de incluir todos eles na API mesclada é renomear o campo para algo semelhante, mas diferente. Para mostrar o esquema de utilitário fornecido pelas diretivas, considere o seguinte exemplo: Neste exemplo, vamos supor que queremos mesclar duas fontes APIs. 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 do GraphQL que permite ao usuário criar `Posts`usando a mutação `putPost`. 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 do GraphQL que funciona muito semelhante ao *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. Além disso, observe como o *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: + O tipo `User` de *Source1.graphql* foi priorizado em relação a `User` de *Source2.graphql* por causa da anotação *@canonical*. + O `Message` tipo do *Source1.graphql* foi incluído na mesclagem. No entanto, o `Message` do *source2.graphql* teve um conflito de nomenclatura. Devido à anotação *@renamed*, ele também foi incluído na mesclagem, mas com o nome alternativo `ChatMessage`. + O tipo `Post` de *Source1.graphql* foi incluído, mas o tipo `Post` de *Source2.graphql* não. Normalmente, haveria um conflito nesse tipo, mas como o tipo `Post` de *Source2.graphql* tinha uma anotação *@hidden*, seus dados foram ofuscados e não incluídos na mesclagem. Isso não resultou em conflitos. + O tipo `Query` foi atualizado para incluir o conteúdo dos dois arquivos. No entanto, uma consulta `GetMessage` foi renomeada para `GetChatMessage` devido à diretiva. Isso resolveu o conflito de nomenclatura entre as duas consultas com o mesmo nome. 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 recuperar `Posts`. 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). As `Reviews` estão associadas ao `Post` do mesmo valor 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: + O tipo `Mutation` não enfrentou conflitos e foi mesclado. + Os campos do tipo `Post` foram combinados por meio da operação de união. Observe como a união entre os dois produziu um único `id`, um `title` e um único `reviews`. + O tipo `Review` não enfrentou conflitos e foi mesclado. + O tipo `Query` não enfrentou conflitos e foi mesclado. ### Gerenciar resolvedores em tipos compartilhados No exemplo acima, considere o caso em que o *Source1.graphql* configurou um resolvedor de unidades em `Query.getPost`, que usa uma fonte de dados do DynamoDB chamada `PostDatasource`. Esse resolvedor retornará o `id` e `title` de um tipo `Post`. Agora, considere que *Source2.graphql* configurou um resolvedor de pipeline em `Post.reviews`, que executa duas funções. `Function1` tem uma fonte de dados `None` anexada para realizar verificações de autorização personalizadas. `Function2` tem uma fonte de dados do DynamoDB anexada para consultar a tabela `reviews`. ``` 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` from`Source1`, que chama `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 em que também implementamos um resolvedor em `Query.getPost` para fornecer vários campos ao mesmo tempo além do resolvedor de campo em `Source2`. *Source1.graphql* pode parecer da seguinte forma: ``` # This snippet represents a file called Source1.graphql type Post { id: ID! title: String! date: AWSDateTime! } type Query { getPost(id: ID!): Post } ``` *Source2.graphql* pode parecer da seguinte forma: ``` # 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 o AWS AppSync Merged APIs não permite que vários resolvedores de origem sejam anexados ao mesmo campo. Para resolver esse conflito, você pode implementar um padrão de resolvedor de campo que exigiria que o *Source2.graphql* adicionasse um tipo separado que definirá os campos que ele possui do tipo `Post`. No exemplo a seguir, adicionamos um tipo chamado `PostInfo`, que contém os campos de conteúdo e autor que serão resolvidos pelo *Source2.graphql*. O *Source1.graphql* implementará o resolvedor anexado a `Query.getPost`, enquanto o *Source2.graphql* agora anexará um resolvedor a `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. ## Configurar esquemas Duas partes são responsáveis por configurar os esquemas para criar uma API mesclada: + **Proprietários da API mesclada** - Os proprietários da API mesclada devem definir a lógica de autorização e as configurações avançadas da API mesclada, como registro em log, rastreamento, armazenamento em cache e suporte ao WAF. + **Proprietários da API de origem associada** - Os proprietários da API associada devem configurar os esquemas, os resolvedores e as fontes de dados que compõem a API mesclada. **Como o esquema da API mesclada é criado a partir dos esquemas da fonte associada APIs, ele é somente para leitura.** Isso significa que as alterações no esquema devem ser iniciadas em sua fonte APIs. **No AWS AppSync console, você pode alternar entre o esquema mesclado e os esquemas individuais da fonte APIs incluídos 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](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html). Os seguintes modos de autorização estão disponíveis para uso com o Merged APIs: + **Chave de API**: a estratégia de autorização mais simples. Todas as solicitações devem incluir uma chave de API no cabeçalho da solicitação `x-api-key`. As chaves de API expiradas são mantidas por 60 dias após a data de expiração. + **AWS Identity and Access Management (IAM)****: a estratégia de autorização AWS do IAM autoriza todas as solicitações assinadas com sigv4.** + **Grupos de usuários do Amazon Cognito**: autorize seus usuários por meio dos grupos de usuários do Amazon Cognito para obter um controle mais refinado. + **AWS Autorizadores Lambda**: uma função sem servidor que permite autenticar e autorizar o acesso à sua API usando lógica personalizada. AWS AppSync + **OpenID Connect**: esse tipo de autorização impõe tokens do OpenID Connect (OIDC) fornecidos por um serviço compatível com OIDC. O aplicativo pode aproveitar os usuários e os privilégios definidos pelo provedor de OIDC para controlar o acesso. 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 na origem APIs, 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 AWS Identity and Access Management (IAM) usada AWS pelos 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 em sua fonte. APIs A função de serviço necessária para isso é a`mergedApiExecutionRole`, e ela deve ter acesso explícito para executar solicitações na fonte APIs incluída em sua API mesclada por meio da permissão do `appsync:SourceGraphQL` IAM. 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 ação. `appsync:SourceGraphQL` AWS AppSync suporta permitir ou negar essa permissão em campos específicos de nível superior dentro da solicitação, como o modo de autorização do IAM funciona para o IAM. APIs Para non-top-level campos, é AWS AppSync necessário definir a permissão no próprio ARN da API de origem. *Para restringir o acesso a non-top-level campos específicos 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/", "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] }] } ``` ------ Você também pode usar o assistente de criação de API do AWS AppSync console para gerar uma função de serviço para permitir que sua API mesclada acesse recursos configurados na fonte APIs que estão na mesma conta da sua API mesclada. Caso sua fonte não APIs esteja na mesma conta da API mesclada, você deve primeiro compartilhar seus AWS recursos usando o Resource Access Manager (AWS RAM). ## Configurando contas cruzadas mescladas usando APIs AWS RAM Ao criar uma API mesclada, você pode, opcionalmente, associar a fonte APIs 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 se integra AWS RAM para oferecer suporte à configuração e ao acesso à fonte APIs 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 no 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: 1. `AWSRAMPermissionAppSyncSourceApiOperationAccess`: o conjunto de permissões padrão que é adicionado ao compartilhar uma AWS AppSync API AWS RAM se nenhuma outra permissão for especificada. Esse conjunto de permissões é usado para compartilhar uma AWS AppSync API de origem com um proprietário da API mesclada. Esse conjunto de permissões inclui a permissão para `appsync:AssociateMergedGraphqlApi` a API de origem, bem como a permissão `appsync:SourceGraphQL` necessária para acessar os atributos da API de origem em runtime. 1. `AWSRAMPermissionAppSyncMergedApiOperationAccess`: esse conjunto de permissões deve ser configurado ao compartilhar uma API mesclada com o proprietário da API de origem. Esse conjunto de permissões dará à API de origem a capacidade de configurar a API mesclada, incluindo a capacidade de associar qualquer fonte APIs pertencente ao principal de destino à API mesclada e de ler e atualizar as associações de API de origem da API mesclada. 1. `AWSRAMPermissionAppSyncAllowSourceGraphQLAccess`: esse conjunto de permissões permite que a `appsync:SourceGraphQL` permissão seja usada com uma AWS AppSync API. Ele deve ser usado para compartilhar uma API de origem com um proprietário da API mesclada. Ao contrário do conjunto de permissões padrão para acesso à operação da API de origem, esse conjunto de permissões inclui apenas a permissão de runtime `appsync:SourceGraphQL`. Se um usuário optar por compartilhar o acesso à operação da API mesclada com um proprietário da API de origem, ele também precisará compartilhar essa permissão da API de origem com o proprietário da API mesclada para ter acesso de runtime por meio do endpoint da API mesclada. 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. As permissões gerenciadas pelo cliente 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 de recursos compartilhados. AWS RAM AWS AppSync permite que você escolha entre as seguintes ações ao criar sua própria permissão: 1. `appsync:AssociateSourceGraphqlApi` 1. `appsync:AssociateMergedGraphqlApi` 1. `appsync:GetSourceApiAssociation` 1. `appsync:UpdateSourceApiAssociation` 1. `appsync:StartSchemaMerge` 1. `appsync:ListTypesByAssociation` 1. `appsync:SourceGraphQL` Depois de compartilhar adequadamente uma API de origem ou API mesclada AWS RAM e, se necessário, o convite de compartilhamento de recursos ter sido aceito, ele ficará visível no AWS AppSync console quando você criar ou atualizar as associações da API de origem na sua API mesclada. Você também pode listar tudo o AWS AppSync APIs que foi compartilhado usando AWS RAM sua conta, independentemente da permissão definida, chamando a `ListGraphqlApis` operação fornecida por AWS AppSync e usando o filtro do `OTHER_ACCOUNTS` proprietário. **nota** O compartilhamento via AWS RAM exige que o chamador tenha permissão para realizar a `appsync:PutResourcePolicy` ação em qualquer API que esteja sendo compartilhada. AWS RAM ## Mesclar ### Gerenciar mesclagens APIs Os mesclados têm como objetivo apoiar a colaboração da equipe em um AWS AppSync endpoint unificado. As equipes podem desenvolver de forma independente sua própria fonte isolada de APIs GraphQL no back-end, enquanto AWS AppSync o serviço gerencia a integração dos recursos em um único endpoint de API mesclada, a fim de reduzir o atrito na colaboração e diminuir os prazos de desenvolvimento. ### Mesclagens automáticas A fonte APIs associada à sua API AWS AppSync mesclada pode ser configurada para ser mesclada automaticamente (mesclagem automática) 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 de 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 --association-id ``` Isso produzirá um resultado no seguinte formato: ``` { "sourceApiAssociation": { "associationId": "", "associationArn": "", "sourceApiId": "", "sourceApiArn": "", "mergedApiArn": "", "mergedApiId": "", "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 na fonte APIs desde a última atualização da API mesclada, o proprietário da API de origem pode invocar uma mesclagem manual a partir do AWS AppSync console ou por meio da `StartSchemaMerge` operação disponível no SDK AWS e na CLI. AWS ## Suporte adicional para Merged APIs ### Configurar assinaturas Ao contrário das abordagens baseadas em roteador para a composição do esquema do GraphQL, o AWS AppSync Merged fornece suporte APIs integrado para assinaturas do GraphQL. Todas as operações de assinatura definidas em sua fonte associada APIs 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 Dados em tempo real.](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html) ### Configurar a observabilidade AWS AppSync O Merged APIs fornece registro, monitoramento e métricas integrados via [Amazon CloudWatch](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html). AWS AppSync também fornece suporte integrado para rastreamento via [AWS X-Ray](https://docs.aws.amazon.com/appsync/latest/devguide/x-ray-tracing.html). ### Configurar domínios personalizados AWS AppSync [O Merged APIs fornece suporte integrado para o uso de domínios personalizados com o GraphQL e os endpoints em tempo real da API Merged.](https://docs.aws.amazon.com/appsync/latest/devguide/custom-domain-name.html) ### Configurar o cache AWS AppSync O Merged APIs fornece suporte integrado para armazenar, opcionalmente, em cache as respostas em nível de solicitação e/ou em nível de resolvedor, bem como compactação de respostas. Para saber mais, consulte [Armazenamento em cache e compactação](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html). ### Configurando o privado APIs AWS AppSync [O Merged APIs fornece suporte integrado para Private, APIs que limita o acesso aos endpoints GraphQL e Real-time da API mesclada ao tráfego proveniente de endpoints VPC que você pode configurar.](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html) ### Configurar regras de firewall AWS AppSync O Merged APIs fornece suporte integrado para AWS WAF, o que permite que você proteja você APIs definindo [regras de firewall de aplicativos web](https://docs.aws.amazon.com/appsync/latest/devguide/WAF-Integration.html). ### Configurar logs de auditoria AWS AppSync O Merged APIs fornece suporte integrado para AWS CloudTrail, o que permite [configurar e gerenciar registros de auditoria](https://docs.aws.amazon.com/appsync/latest/devguide/cloudtrail-logging.html). ## Limitações de APIs mescladas Ao desenvolver o Merged APIs, observe as seguintes regras: 1. Uma API mesclada não pode ser uma API de origem para outra API mesclada. 1. Uma API de origem não pode ser associada a mais de uma API mesclada. 1. O limite de tamanho padrão para um documento do esquema da API mesclada é de 10 MB. 1. O número padrão de fontes APIs que pode ser associado a uma API mesclada é 10. No entanto, você pode solicitar um aumento de limite se precisar de mais de 10 fontes APIs em sua API mesclada. ## Considerações sobre a API mesclada Ao projetar e implementar o Merged APIs, considere o seguinte: A fusão de várias fontes APIs 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 fontes APIs 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 seu Merged APIs minuciosamente durante o desenvolvimento e sob condições de carga realistas para garantir que ele atenda aos requisitos de sua empresa. Preste atenção específica a: + A profundidade e a complexidade do seu esquema mesclado, especialmente consultas que acessam campos em várias fontes. APIs + O número de resolvedores que devem ser executados para atender aos padrões de consulta comuns. + As características de desempenho de suas fontes de dados e resolvedores sob carga esperada. + O impacto da latência da rede ao acessar recursos em várias fontes APIs. Considere implementar otimizações de desempenho, como armazenamento em cache, agrupamento de solicitações de fontes de dados em lote e design de seus esquemas de API de origem para minimizar o número de execuções de resolvedor necessárias para operações comuns. ## Criando mesclado APIs **Para criar uma API mesclada no console** 1. Faça login no Console de gerenciamento da AWS e abra o [AWS AppSync console](https://console.aws.amazon.com/appsync/). 1. No **Painel**, selecione **Criar API**. 1. Selecione **API mesclada** e, em seguida, **Avançar**. 1. Na página **Especificar detalhes da API**, insira as seguintes informações: 1. Em **Detalhes da API**, insira as seguintes informações: 1. Especifique o **nome da API** da API mesclada. Esse campo é uma forma de rotular sua API do GraphQL para diferenciá-la convenientemente de outros GraphQL. APIs 1. Especifique os **detalhes de contato**. Esse campo é opcional e anexa um nome ou grupo à API do GraphQL. Ele não é vinculado ou gerado por outros atributos e funciona da mesma forma que o campo de nome da API. 1. Em **Função de serviço**, você deve anexar uma função de execução do IAM à sua API mesclada para que AWS AppSync possa importar e usar seus recursos com segurança em tempo de execução. Você pode escolher **criar e usar uma nova função de serviço**, o que permitirá especificar as políticas e os recursos que AWS AppSync serão usados. Você também pode importar um perfil do IAM existente escolhendo **Usar um perfil de serviço existente** e selecionando um perfil na lista suspensa. 1. Em **Configuração da API privada**, é possível ativar os atributos da API privada. Observe que essa opção não pode ser alterada após a criação da API mesclada. Para obter mais informações sobre privacidade APIs, consulte Como [usar o AWS AppSync privado APIs](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html). Quando terminar, selecione **Avançar**. 1. Em seguida, você deve adicionar o GraphQL APIs que será usado como base para sua API mesclada. Na APIs página **Selecionar fonte**, insira as seguintes informações: 1. Na tabela **APIs da sua AWS conta**, escolha **Adicionar fonte APIs**. Na lista do GraphQL APIs, cada entrada conterá os seguintes dados: 1. **Nome**: o campo **nome da API** da API do GraphQL. 1. **ID da API**: o valor de ID exclusivo da API do GraphQL. 1. **Modo de autenticação primária**: o modo de autorização padrão para a API do GraphQL. Para obter mais informações sobre os modos de autorização no AWS AppSync, consulte [Autorização e autenticação](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html). 1. **Modo de autenticação adicional**: os modos de autorização secundários que foram configurados na API do GraphQL. 1. Escolha o APIs que você usará na API mesclada marcando a caixa de seleção ao lado do campo **Nome** da API. Depois, escolha **Adicionar fonte APIs**. O GraphQL selecionado APIs aparecerá na tabela **APIs de suas AWS contas**. 1. Na tabela **APIs De outras AWS contas**, escolha **Adicionar fonte APIs**. O GraphQL APIs nesta lista vem de outras contas que estão compartilhando seus recursos com a sua por meio de AWS Resource Access Manager ()AWS RAM. O processo para selecionar o GraphQL APIs nesta tabela é o mesmo da seção anterior. Para obter mais informações sobre o compartilhamento de recursos por meio de AWS RAM, consulte [O que é AWS Resource Access Manager?](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) . Quando terminar, selecione **Avançar**. 1. Adicione seu modo de autenticação principal. Consulte [Autorização e autenticação](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html) para obter mais informações. Selecione **Avançar**. 1. Revise suas entradas e selecione **Criar API**.