API unite - AWS AppSync
API e federazione uniteRisoluzione unificata dei conflitti tramite APIConfigurazione degli schemiConfigurazione delle modalità di autorizzazioneConfigurazione dei ruoli di esecuzioneConfigurazione delle API unite tra account utilizzando AWS RAMUnireSupporto aggiuntivo per le API uniteLimitazioni delle API uniteCreazione di API unite

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

API unite

Man mano che l'uso di GraphQL si espande all'interno di un'organizzazione, possono sorgere compromessi tra API ease-of-use e velocità di sviluppo delle API. Da un lato, le organizzazioni adottano AWS AppSync GraphQL per semplificare lo sviluppo di applicazioni offrendo agli sviluppatori un'API flessibile che possono utilizzare per accedere, manipolare e combinare in modo sicuro i dati di uno o più domini di dati con una singola chiamata di rete. D'altra parte, i team all'interno di un'organizzazione responsabili dei diversi domini di dati combinati in un unico endpoint dell'API GraphQL potrebbero desiderare la possibilità di creare, gestire e distribuire gli aggiornamenti delle API indipendentemente l'uno dall'altro per aumentare le proprie velocità di sviluppo.

Per risolvere questa tensione, la funzionalità AWS AppSync Merged APIs consente ai team di diversi domini di dati di creare e distribuire AWS AppSync API in modo indipendente (ad esempio schemi GraphQL, resolver, fonti di dati e funzioni), che possono quindi essere combinate in un'unica API unita. Ciò offre alle organizzazioni la possibilità di mantenere un'API interdominio semplice da usare e un modo per i diversi team che contribuiscono a tale API di effettuare aggiornamenti delle API in modo rapido e indipendente.

Utilizzando le API unite, le organizzazioni possono importare le risorse di più API di origine indipendenti in un unico endpoint di AWS AppSync API AWS AppSync unite. A tale scopo, AWS AppSync consente di creare un elenco di API di AWS AppSync origine e quindi unire tutti i metadati associati alle API di origine, inclusi schemi, tipi, origini dati, resolver e funzioni, in una nuova API unita. AWS AppSync

Durante le unioni, esiste la possibilità che si verifichi un conflitto di fusione a causa di incongruenze nel contenuto dei dati dell'API di origine, ad esempio conflitti di denominazione dei tipi quando si combinano più schemi. Per casi d'uso semplici in cui nessuna definizione nelle API di origine è in conflitto, non è necessario modificare gli schemi delle API di origine. L'API Merged risultante importa semplicemente tutti i tipi, i resolver, le fonti di dati e le funzioni dalle API di origine originali. AWS AppSync Nei casi d'uso complessi in cui sorgono conflitti, gli utenti/team dovranno risolvere i conflitti con vari mezzi. AWS AppSyncfornisce agli utenti diversi strumenti ed esempi in grado di ridurre i conflitti di fusione.

Le fusioni successive configurate in AWS AppSync propagheranno le modifiche apportate alle API di origine all'API unita associata.

API e federazione unite

Esistono molte soluzioni e modelli nella community GraphQL per combinare schemi GraphQL e consentire la collaborazione in team attraverso un grafico condiviso. AWS AppSync Le API unite adottano un approccio alla composizione dello schema in fase di compilazione, in cui le API di origine vengono combinate in un'API unita separata. Un approccio alternativo consiste nel sovrapporre un router in fase di esecuzione su più API o sottografi di origine. In questo approccio, il router riceve una richiesta, fa riferimento a uno schema combinato che mantiene come metadati, crea un piano di richiesta e quindi distribuisce gli elementi della richiesta tra i sotto-grafici/server sottostanti. La tabella seguente confronta l'approccio in fase di compilazione dell'AWS AppSyncAPI unita con gli approcci in fase di esecuzione basati su router alla composizione dello schema GraphQL:

Feature AppSync Merged API Router-based solutions
Sub-graphs managed independently Yes Yes
Sub-graphs addressable independently Yes Yes
Automated schema composition Yes Yes
Automated conflict detection Yes Yes
Conflict resolution via schema directives Yes Yes
Supported sub-graph servers AWS AppSync* Varies
Network complexity Single, merged API means no extra network hops. Multi-layer architecture requires query planning and delegation, sub-query parsing and serialization/deserialization, and reference resolvers in sub-graphs to perform joins.
Observability support Built-in monitoring, logging, and tracing. A single, Merged API server means simplified debugging. Build-your-own observability across router and all associated sub-graph servers. Complex debugging across distributed system.
Authorization support Built in support for multiple authorization modes. Build-your-own authorization rules.
Cross account security Built-in support for cross-AWS cloud account associations. Build-your-own security model.
Subscriptions support Yes No

* Le API unite possono essere associate solo alle API di origine. AWS AppSync AWS AppSync Se hai bisogno di supporto per la composizione dello schema tra AWS AppSync e non AWS AppSync sotto grafici, puoi connettere una o più API GraphQL AWS AppSync e/o Merged in una soluzione basata su router. Ad esempio, consulta il blog di riferimento per aggiungere AWS AppSync API come sottografo utilizzando un'architettura basata su router con Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync

Risoluzione unificata dei conflitti tramite API

In caso di conflitto di fusione, AWS AppSync fornisce agli utenti diversi strumenti ed esempi per aiutare a risolvere il/i problema/i.

Direttive dello schema API unite

AWS AppSyncha introdotto diverse direttive GraphQL che possono essere utilizzate per ridurre o risolvere i conflitti tra le API di origine:

  • @canonical: questa direttiva imposta la precedenza di tipi/campi con nomi e dati simili. Se due o più API di origine hanno lo stesso tipo o campo GraphQL, una delle API può annotare il tipo o il campo come canonico, a cui verrà assegnata la priorità durante l'unione. I tipi/campi in conflitto che non sono annotati con questa direttiva in altre API di origine vengono ignorati quando vengono uniti.

  • @hidden: questa direttiva incapsula determinati tipi/campi per rimuoverli dal processo di fusione. I team potrebbero voler rimuovere o nascondere tipi o operazioni specifici nell'API di origine in modo che solo i client interni possano accedere a dati digitati specifici. Con questa direttiva allegata, i tipi o i campi non vengono uniti nell'API Merged.

  • @renamed: questa direttiva modifica i nomi dei tipi/campi per ridurre i conflitti di denominazione. Esistono situazioni in cui API diverse hanno lo stesso tipo o nome di campo. Tuttavia, devono essere tutte disponibili nello schema unito. Un modo semplice per includerli tutti nell'API Merged consiste nel rinominare il campo con qualcosa di simile ma diverso.

Per mostrare lo schema di utilità fornito dalle direttive, considera il seguente esempio:

In questo esempio, supponiamo di voler unire due API di origine. Ci vengono forniti due schemi per creare e recuperare post (ad esempio, sezione commenti o post sui social media). Supponendo che i tipi e i campi siano molto simili, c'è un'alta probabilità di conflitto durante un'operazione di unione. I frammenti seguenti mostrano i tipi e i campi di ogni schema.

Il primo file, chiamato Source1.graphQL, è uno schema GraphQL che consente a un utente di creare utilizzando la mutazione. Posts putPost Ciascuno Post contiene un titolo e un ID. L'ID viene utilizzato per fare riferimento alle informazioni del poster (e-mail e indirizzo) e alMessage, o al payload (contenuto). User Il User tipo è annotato con il 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
}

Il secondo file, chiamato Source2.graphQL, è uno schema GraphQL che fa cose molto simili a Source1.graphQL. Tuttavia, notate che i campi di ogni tipo sono diversi. Quando si uniscono questi due schemi, si verificheranno conflitti di unione dovuti a queste differenze.

Nota anche come Source2.graphQL contenga anche diverse direttive per ridurre questi conflitti. Il Post tipo è annotato con un tag @hidden per offuscarsi durante l'operazione di unione. Il Message tipo è annotato con il tag @renamed per modificare il nome del tipo ChatMessage in caso di conflitto di denominazione con un altro 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 si verifica l'unione, il risultato produrrà il file: 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
}

Durante l'unione si sono verificate diverse cose:

  • Il User tipo di Source1.graphQL ha avuto la priorità rispetto a quello di Source2.graphQL grazie all'annotazione User @canonical.

  • Il Message tipo di Source1.graphQL è stato incluso nell'unione. Tuttavia, il file di Source2.graphQL presentava un Message conflitto di denominazione. Grazie alla sua annotazione @renamed, è stata inclusa anche nell'unione ma con il nome alternativo. ChatMessage

  • Il Post tipo di Source1.graphQL è stato incluso, ma non il tipo di Source2.graphQL. Post Normalmente, si verificava un conflitto su questo tipo, ma poiché il Post tipo di Source2.GraphQL aveva un'annotazione @hidden, i suoi dati erano offuscati e non inclusi nell'unione. Ciò non ha provocato conflitti.

  • Il Query tipo è stato aggiornato per includere il contenuto di entrambi i file. Tuttavia, una GetMessage query è stata rinominata in GetChatMessage base alla direttiva. Ciò ha risolto il conflitto di denominazione tra le due query con lo stesso nome.

C'è anche il caso in cui nessuna direttiva venga aggiunta a un tipo in conflitto. Qui, il tipo unito includerà l'unione di tutti i campi di tutte le definizioni di origine di quel tipo. Ad esempio, si consideri il seguente esempio:

Questo schema, chiamato Source1.graphQL, consente la creazione e il recupero. Posts La configurazione è simile all'esempio precedente, ma con meno informazioni.

# 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
}

Questo schema, chiamato Source2.GraphQL, consente di creare e recuperare Reviews (ad esempio, la valutazione dei film o le recensioni dei ristoranti). Reviewssono associati allo stesso valore ID. Post Insieme, contengono il titolo, l'ID del post e il messaggio di payload del post completo della recensione.

Durante la fusione, si verificherà un conflitto tra i due Post tipi. Poiché non esistono annotazioni per risolvere questo problema, il comportamento predefinito consiste nell'eseguire un'operazione di unione sui tipi in conflitto.

# 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 si verifica l'unione, il risultato produrrà il file: 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
}

Durante l'unione si sono verificate diverse cose:

  • Il Mutation tipo non ha avuto conflitti ed è stato unito.

  • I campi Post tipo sono stati combinati tramite un'operazione di unione. Notate come l'unione tra i due abbia prodotto un singolo idtitle, un e un singoloreviews.

  • Il Review tipo non ha subito conflitti ed è stato unito.

  • Il Query tipo non ha riscontrato conflitti ed è stato unito.

Gestione dei resolver su tipi condivisi

Nell'esempio precedente, considera il caso in cui Source1.GraphQL ha configurato un resolver di unità su, Query.getPost che utilizza un'origine dati DynamoDB denominata. PostDatasource Questo resolver restituirà un tipo e. id title Post Consideriamo ora che Source2.graphQL ha configurato un resolver di pipeline su, che esegue due funzioni. Post.reviews Function1ha una fonte di None dati allegata per eseguire controlli di autorizzazione personalizzati. Function2ha un'origine dati DynamoDB allegata per interrogare la tabella. reviews

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

Quando la query precedente viene eseguita da un client all'endpoint Merged API, il AWS AppSync servizio esegue innanzitutto il resolver di unità per Query.getPost fromSource1, che chiama PostDatasource e restituisce i dati da DynamoDB. Quindi, esegue il resolver della Post.reviews pipeline in cui Function1 esegue una logica di autorizzazione personalizzata e restituisce le recensioni fornite. Function2 id $context.source Il servizio elabora la richiesta come una singola esecuzione GraphQL e questa semplice richiesta richiederà solo un singolo token di richiesta.

Gestione dei conflitti dei resolver su tipi condivisi

Considera il seguente caso in cui implementiamo anche un resolver on per fornire più campi contemporaneamente oltre al resolver di campo Query.getPost in cui è inserito. Source2 Source1.graphQL può assomigliare a questo:

# This snippet represents a file called Source1.graphql

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

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

Source2.graphQL può assomigliare a questo:

# This snippet represents a file called Source2.graphql

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

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

Il tentativo di unire questi due schemi genererà un errore di unione perché le API AWS AppSync unite non consentono di collegare più resolver di origine allo stesso campo. Per risolvere questo conflitto, puoi implementare un pattern di risoluzione dei campi che richiederebbe a Source2.GraphQL di aggiungere un tipo separato che definirà i campi di sua proprietà rispetto al tipo. Post Nell'esempio seguente, aggiungiamo un tipo chiamatoPostInfo, che contiene i campi content e author che verranno risolti da Source2.graphQL. Source1.graphQL implementerà il resolver collegato aQuery.getPost, mentre Source2.graphQL ora collegherà un resolver per garantire che tutti i dati possano essere recuperati con successo: Post.postInfo

type Post  {
  id: ID!
  postInfo: PostInfo
}

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

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

Sebbene la risoluzione di tale conflitto richieda la riscrittura degli schemi delle API di origine e, potenzialmente, la modifica delle query da parte dei clienti, il vantaggio di questo approccio è che la proprietà dei resolver uniti rimane chiara tra i team di origine.

Configurazione degli schemi

Due parti sono responsabili della configurazione degli schemi per la creazione di un'API unita:

  • Proprietari delle API unite: i proprietari delle API unite devono configurare la logica di autorizzazione dell'API unita e le impostazioni avanzate come la registrazione, il tracciamento, la memorizzazione nella cache e il supporto WAF.

  • Proprietari delle API di origine associate: i proprietari delle API associate devono configurare gli schemi, i resolver e le origini dati che compongono l'API unita.

Poiché lo schema dell'API unita viene creato dagli schemi delle API di origine associate, è di sola lettura. Ciò significa che le modifiche allo schema devono essere avviate nelle API di origine. Nella AWS AppSync console, puoi passare dallo schema Merged ai singoli schemi delle API di origine incluse nell'API Merged utilizzando l'elenco a discesa sopra la finestra Schema.

Configurazione delle modalità di autorizzazione

Sono disponibili diverse modalità di autorizzazione per proteggere l'API unita. Per ulteriori informazioni sulle modalità di autorizzazione inAWS AppSync, consulta Autorizzazione e autenticazione.

Le seguenti modalità di autorizzazione sono disponibili per l'uso con le API unite:

  • Chiave API: la strategia di autorizzazione più semplice. Tutte le richieste devono includere una chiave API sotto l'intestazione della x-api-key richiesta. Le chiavi API scadute vengono conservate per 60 giorni dopo la data di scadenza.

  • AWSIdentity and Access Management (IAM): AWS la strategia di autorizzazione IAM autorizza tutte le richieste firmate con sigv4.

  • Pool di utenti Amazon Cognito: autorizza i tuoi utenti tramite i pool di utenti di Amazon Cognito per ottenere un controllo più preciso.

  • AWSAutorizzatori Lambda: una funzione serverless che consente di autenticare e autorizzare l'accesso all'API utilizzando una logica personalizzata. AWS AppSync

  • OpenID Connect: questo tipo di autorizzazione applica i token OpenID connect (OIDC) forniti da un servizio conforme a OIDC. La tua applicazione può usare gli utenti e i privilegi definiti dal provider OIDC per controllare l'accesso.

Le modalità di autorizzazione di un'API unita sono configurate dal proprietario dell'API unita. Al momento di un'operazione di unione, l'API unita deve includere la modalità di autorizzazione principale configurata su un'API di origine come modalità di autorizzazione principale propria o come modalità di autorizzazione secondaria. In caso contrario, sarà incompatibile e l'operazione di unione avrà esito negativo a causa di un conflitto. Quando si utilizzano direttive multi-auth nelle API di origine, il processo di fusione è in grado di unire automaticamente queste direttive nell'endpoint unificato. Nel caso in cui la modalità di autorizzazione principale dell'API di origine non corrisponda alla modalità di autorizzazione principale dell'API unita, aggiungerà automaticamente queste direttive di autenticazione per garantire che la modalità di autorizzazione per i tipi nell'API di origine sia coerente.

Configurazione dei ruoli di esecuzione

Quando si crea un'API unita, è necessario definire un ruolo di servizio. Un ruolo AWS di servizio è un ruolo di AWS Identity and Access Management (IAM) utilizzato AWS dai servizi per eseguire attività per conto dell'utente.

In questo contesto, è necessario che l'API Merged esegua resolver che accedano ai dati dalle fonti di dati configurate nelle API di origine. Il ruolo di servizio richiesto a tal fine èmergedApiExecutionRole, e deve disporre dell'accesso esplicito all'esecuzione delle richieste sulle API di origine incluse nell'API unita tramite l'autorizzazione IAM. appsync:SourceGraphQL Durante l'esecuzione di una richiesta GraphQL, il AWS AppSync servizio assumerà questo ruolo di servizio e autorizzerà il ruolo a eseguire l'azione. appsync:SourceGraphQL

AWS AppSyncsupporta l'autorizzazione o la negazione di questa autorizzazione su campi specifici di primo livello all'interno della richiesta, ad esempio il funzionamento della modalità di autorizzazione IAM per le API IAM. Per non-top-level i campi, AWS AppSync richiede di definire l'autorizzazione sull'ARN dell'API di origine stesso. Per limitare l'accesso a non-top-level campi specifici nell'API Merged, ti consigliamo di implementare una logica personalizzata all'interno di Lambda o di nascondere i campi dell'API di origine all'API Merged utilizzando la direttiva @hidden. Se desideri consentire al ruolo di eseguire tutte le operazioni sui dati all'interno di un'API di origine, puoi aggiungere la politica seguente. Tieni presente che la prima voce di risorsa consente l'accesso a tutti i campi di primo livello e la seconda voce riguarda i resolver secondari che autorizzano la risorsa API di origine stessa: 

{
    "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 desideri limitare l'accesso solo a uno specifico campo di primo livello, puoi utilizzare una politica come questa:

{
    "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"] 
    }] 
}

Puoi anche utilizzare la procedura guidata di creazione dell'API della AWS AppSync console per generare un ruolo di servizio che consenta all'API unita di accedere alle risorse configurate nelle API di origine che si trovano nello stesso account dell'API unita. Nel caso in cui le API di origine non si trovino nello stesso account dell'API unita, è necessario innanzitutto condividere le AWS risorse utilizzando Resource Access Manager ()AWS RAM.

Configurazione delle API unite tra account utilizzando AWS RAM

Quando crei un'API unita, puoi facoltativamente associare le API di origine di altri account che sono stati condivisi tramite AWS Resource Access Manager (). AWS RAM AWS RAMti aiuta a condividere le tue risorse in modo sicuro tra AWS gli account, all'interno dell'organizzazione o delle unità organizzative (OU) e con i ruoli e gli utenti IAM.

AWS AppSyncsi integra con AWS RAM per supportare la configurazione e l'accesso alle API di origine su più account da un'unica API unita. AWS RAMconsente di creare una condivisione di risorse o un contenitore di risorse e i set di autorizzazioni che verranno condivisi per ciascuna di esse. Puoi aggiungere AWS AppSync API a una condivisione di risorse inAWS RAM. All'interno di una condivisione di risorse, AWS AppSync fornisce tre diversi set di autorizzazioni che possono essere associati a un'AWS AppSyncAPI nella RAM:

  1. AWSRAMPermissionAppSyncSourceApiOperationAccess: il set di autorizzazioni predefinito che viene aggiunto quando si condivide un'AWS AppSyncAPI AWS RAM se non viene specificata nessun'altra autorizzazione. Questo set di autorizzazioni viene utilizzato per condividere un'AWS AppSyncAPI di origine con un proprietario di un'API unita. Questo set di autorizzazioni include l'autorizzazione per appsync:AssociateMergedGraphqlApi l'API di origine e l'appsync:SourceGraphQLautorizzazione richiesta per accedere alle risorse dell'API di origine in fase di esecuzione.

  2. AWSRAMPermissionAppSyncMergedApiOperationAccess: questo set di autorizzazioni deve essere configurato quando si condivide un'API unita con un proprietario dell'API di origine. Questo set di autorizzazioni darà all'API di origine la possibilità di configurare l'API unita, inclusa la possibilità di associare qualsiasi API di origine di proprietà del principale di destinazione all'API unita e di leggere e aggiornare le associazioni delle API di origine dell'API unita.

  3. AWSRAMPermissionAppSyncAllowSourceGraphQLAccess: Questo set di autorizzazioni consente di utilizzare l'appsync:SourceGraphQLautorizzazione con un'API. AWS AppSync È destinato a essere utilizzato per condividere un'API di origine con un proprietario di un'API unita. A differenza del set di autorizzazioni predefinito per l'accesso alle operazioni dell'API di origine, questo set di autorizzazioni include solo l'autorizzazione appsync:SourceGraphQL di runtime. Se un utente sceglie di condividere l'accesso all'operazione Merged API con un proprietario dell'API di origine, dovrà inoltre condividere questa autorizzazione dall'API di origine al proprietario dell'API unita per avere accesso al runtime tramite l'endpoint dell'API unita.

AWS AppSyncsupporta anche le autorizzazioni gestite dal cliente. Quando una delle autorizzazioni AWS gestite fornite non funziona, puoi creare un'autorizzazione gestita dal cliente personalizzata. Le autorizzazioni gestite dal cliente sono autorizzazioni gestite che puoi creare e gestire specificando con precisione quali azioni possono essere eseguite in quali condizioni con risorse condivise. AWS RAM AWS AppSyncconsente di scegliere tra le seguenti azioni durante la creazione delle proprie autorizzazioni:

  1. appsync:AssociateSourceGraphqlApi

  2. appsync:AssociateMergedGraphqlApi

  3. appsync:GetSourceApiAssociation

  4. appsync:UpdateSourceApiAssociation

  5. appsync:StartSchemaMerge

  6. appsync:ListTypesByAssociation

  7. appsync:SourceGraphQL

Dopo aver condiviso correttamente un'API di origine o un'API unita AWS RAM e, se necessario, l'invito alla condivisione delle risorse è stato accettato, l'invito alla condivisione delle risorse sarà visibile nella AWS AppSync console quando si creano o si aggiornano le associazioni delle API di origine sulla Merged API. Puoi anche elencare tutte le AWS AppSync API che sono state condivise AWS RAM con il tuo account indipendentemente dall'autorizzazione impostata richiamando l'ListGraphqlApisoperazione fornita AWS AppSync e utilizzando il OTHER_ACCOUNTS filtro proprietario.

Nota

La condivisione tramite AWS RAM richiede che il chiamante AWS RAM sia autorizzato a eseguire l'appsync:PutResourcePolicyazione su qualsiasi API condivisa.

Unire

Gestione delle unioni

Le API unite hanno lo scopo di supportare la collaborazione in team su un endpoint unificato. AWS AppSync I team possono sviluppare in modo indipendente le proprie API GraphQL di origine isolate nel backend, mentre AWS AppSync il servizio gestisce l'integrazione delle risorse nel singolo endpoint Merged API per ridurre l'attrito nella collaborazione e ridurre i tempi di sviluppo.

Unioni automatiche

Le API di origine associate all'API AWS AppSync unita possono essere configurate per l'unione automatica (unione automatica) nell'API unita dopo aver apportato modifiche all'API di origine. Ciò garantisce che le modifiche dall'API di origine vengano sempre propagate all'endpoint dell'API unita in background. Qualsiasi modifica nello schema dell'API di origine verrà aggiornata nell'API unita a condizione che non introduca un conflitto di fusione con una definizione esistente nell'API unita. Se l'aggiornamento nell'API di origine sta aggiornando un resolver, un'origine dati o una funzione, verrà aggiornata anche la risorsa importata. Quando viene introdotto un nuovo conflitto che non può essere risolto automaticamente (risolto automaticamente), l'aggiornamento dello schema dell'API unita viene rifiutato a causa di un conflitto non supportato durante l'operazione di unione. Il messaggio di errore è disponibile nella console per ogni associazione di API di origine con lo stato di. MERGE_FAILED Puoi anche controllare il messaggio di errore chiamando l'GetSourceApiAssociationoperazione per una determinata associazione API di origine utilizzando l'AWSSDK o utilizzando la AWS CLI in questo modo:

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

Ciò produrrà un risultato nel seguente 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."
    }
}

Unioni manuali

L'impostazione predefinita per un'API di origine è un'unione manuale. Per unire le modifiche apportate alle API di origine dall'ultimo aggiornamento dell'API unita, il proprietario dell'API di origine può richiamare un'unione manuale dalla AWS AppSync console o tramite l'StartSchemaMergeoperazione disponibile nell'SDK e nella CLI. AWS AWS

Supporto aggiuntivo per le API unite

Configurazione degli abbonamenti

A differenza degli approcci basati su router alla composizione dello schema GraphQL, le API AWS AppSync unite forniscono supporto integrato per gli abbonamenti GraphQL. Tutte le operazioni di sottoscrizione definite nelle API di origine associate verranno automaticamente unite e funzioneranno nell'API Merged senza modifiche. Per ulteriori informazioni su come AWS AppSync supporta gli abbonamenti tramite WebSockets connessione serverless, consulta Dati in tempo reale.

Configurazione dell'osservabilità

AWS AppSyncLe API unite forniscono registrazione, monitoraggio e metriche integrate tramite Amazon. CloudWatch AWS AppSyncfornisce anche supporto integrato per la tracciabilità tramite. AWS X-Ray

Configurazione di domini personalizzati

AWS AppSyncLe API unite forniscono supporto integrato per l'utilizzo di domini personalizzati con gli endpoint GraphQL e Real-time dell'API Merged.

Configurazione della memorizzazione nella cache

AWS AppSyncLe API unite forniscono supporto integrato per la memorizzazione opzionale nella cache delle risposte a livello di richiesta e/o a livello di resolver, nonché per la compressione delle risposte. Per ulteriori informazioni, consulta Caching e compressione.

Configurazione delle API private

AWS AppSyncLe API unite forniscono supporto integrato per le API private che limitano l'accesso agli endpoint GraphQL e Real-time dell'API Merged al traffico proveniente dagli endpoint VPC che puoi configurare.

Configurazione delle regole del firewall

AWS AppSyncLe API unite forniscono un supporto integrato perAWS WAF, che consente di proteggere le API definendo le regole del firewall delle applicazioni Web.

Configurazione dei log di controllo

AWS AppSyncLe API unite forniscono un supporto integrato per AWS CloudTrail, che consente di configurare e gestire i log di controllo.

Limitazioni delle API unite

Quando sviluppi API unite, prendi nota delle seguenti regole:

  1. Un'API unita non può essere un'API di origine per un'altra API unita.

  2. Un'API di origine non può essere associata a più di un'API unita.

  3. Il limite di dimensione predefinito per un documento dello schema dell'API unita è di 10 MB.

  4. Il numero predefinito di API di origine che possono essere associate a un'API unita è 10. Tuttavia, puoi richiedere un aumento del limite se hai bisogno di più di 10 API di origine nella tua API unita.

Creazione di API unite

Per creare un'API unita nella console

  1. Accedere alla AWS Management Console e aprire la console AWS AppSync.

    1. Nella dashboard, scegli Crea API.

  2. Scegli Merged API, quindi scegli Avanti.

  3. Nella pagina Specificare i dettagli dell'API, inserisci le seguenti informazioni:

    1. In Dettagli API, inserisci le seguenti informazioni:

      1. Specificate il nome dell'API unita. Questo campo consente di etichettare l'API GraphQL per distinguerla facilmente dalle altre API GraphQL.

      2. Specificate i dati di contatto. Questo campo è facoltativo e assegna un nome o un gruppo all'API GraphQL. Non è collegato o generato da altre risorse e funziona in modo molto simile al campo del nome dell'API.

    2. In Service role, devi assegnare un ruolo di esecuzione IAM all'API unita in modo che AWS AppSync possa importare e utilizzare le tue risorse in modo sicuro in fase di esecuzione. Puoi scegliere di creare e utilizzare un nuovo ruolo di servizio, che ti consentirà di specificare le politiche e le risorse da utilizzare. AWS AppSync Puoi anche importare un ruolo IAM esistente selezionando Usa un ruolo di servizio esistente, quindi selezionando il ruolo dall'elenco a discesa.

    3. In Configurazione API privata, puoi scegliere di abilitare le funzionalità dell'API privata. Tieni presente che questa scelta non può essere modificata dopo aver creato l'API unita. Per ulteriori informazioni sulle API private, consulta Utilizzo delle API AWS AppSync private.

      Dopo aver finito, scegli Avanti.

  4. Successivamente, è necessario aggiungere le API GraphQL che verranno utilizzate come base per l'API unita. Nella pagina Seleziona le API di origine, inserisci le seguenti informazioni:

    1. Nella tabella delle API del tuo AWS account, scegli Aggiungi API di origine. Nell'elenco delle API GraphQL, ogni voce conterrà i seguenti dati:

      1. Nome: il campo del nome dell'API GraphQL.

      2. ID API: il valore ID univoco dell'API GraphQL.

      3. Modalità di autenticazione primaria: la modalità di autorizzazione predefinita per l'API GraphQL. Per ulteriori informazioni sulle modalità di autorizzazione inAWS AppSync, vedere Autorizzazione e autenticazione.

      4. Modalità di autenticazione aggiuntiva: le modalità di autorizzazione secondarie configurate nell'API GraphQL.

      5. Scegli le API che utilizzerai nell'API unita selezionando la casella di controllo accanto al campo Nome dell'API. Successivamente, scegli Aggiungi API di origine. Le API GraphQL selezionate verranno visualizzate nelle API della tabella degli account. AWS

    2. Nella tabella API di altri AWS account, scegli Aggiungi API di origine. Le API GraphQL in questo elenco provengono da altri account che condividono le proprie risorse con l'utente tramite AWS Resource Access Manager (). AWS RAM Il processo di selezione delle API GraphQL in questa tabella è lo stesso del processo descritto nella sezione precedente. Per ulteriori informazioni sulla condivisione di risorse tramiteAWS RAM, consulta What is? AWS Resource Access Manager .

      Scegli Avanti dopo aver finito.

    3. Aggiungi la tua modalità di autenticazione principale. Vedi Autorizzazione e autenticazione per ulteriori informazioni. Seleziona Avanti.

    4. Controlla i tuoi input, quindi scegli Crea API.