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

Unire le API in AWS AppSync

Man mano che l'uso di GraphQL si espande all'interno di un'organizzazione, possono sorgere compromessi tra facilità d'uso delle API e velocità di sviluppo delle API. Da un lato, le organizzazioni adottano GraphQL per semplificare lo sviluppo delle applicazioni. AWS AppSync Ciò offre agli sviluppatori un'API flessibile che possono utilizzare per accedere, manipolare e combinare in modo sicuro i dati provenienti da 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 API GraphQL potrebbero desiderare la possibilità di creare, gestire e distribuire gli aggiornamenti delle API indipendentemente l'uno dall'altro. Ciò aumenta la loro 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, resolver, origini dati e funzioni GraphQL), che possono poi 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 la possibilità di effettuare aggiornamenti API in modo rapido e indipendente.

Il diagramma seguente mostra il flusso di lavoro delle API unite:

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

Durante le unioni, è possibile che si verifichi un conflitto di unione a causa di incoerenze nel contenuto dei dati dell'API di origine, ad esempio conflitti di denominazione dei tipi quando si combinano più schemi. Per i 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 Per i casi d'uso complessi in cui sorgono conflitti, users/teams dovrà risolvere i conflitti con vari mezzi. AWS AppSync fornisce 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 nelle API di origine all'API unita associata.

API unite e federazione

Esistono molte soluzioni e modelli nella comunità GraphQL per combinare schemi GraphQL e consentire la collaborazione in team tramite un grafico condiviso. AWS AppSync Le API unite adottano un approccio in fase di compilazione alla composizione dello schema, in cui le API di origine vengono combinate in un'API unita separata. Un approccio alternativo consiste nello stratificare 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, costruisce un piano di richiesta e quindi distribuisce gli elementi della richiesta nel sottoinsieme sottostante. graphs/servers La tabella seguente confronta l'approccio in fase di compilazione della AWS AppSync Merged API con gli approcci in fase di esecuzione basati su router alla composizione dello schema GraphQL:

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

Risoluzione dei conflitti tra API unite

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

Direttive dello schema API unito

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

Per mostrare l'utilità fornita dalle direttive dello schema, 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 Posts utilizzando la mutazione. putPost Ciascuno Post contiene un titolo e un ID. L'ID viene utilizzato per fare riferimento alle informazioni del poster (email 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 a causa di queste differenze.

Nota inoltre che contiene Source2.graphql 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 viene 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:

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 recuperoPosts. 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, valutazioni di film o recensioni di ristoranti). Reviewssono associati allo Post stesso valore ID. 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 ci sono 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:

Gestione dei resolver sui tipi condivisi

Nell'esempio precedente, considera il caso in cui Source1.graphql è stato configurato un resolver di unità attivoQuery.getPost, che utilizza una fonte di dati DynamoDB denominata. PostDatasource Questo resolver restituirà il valore and di un tipo. id title Post Ora, considera Source2.graphql ha configurato un pipeline resolver attivoPost.reviews, che esegue due funzioni. Function1ha una fonte di None dati collegata per eseguire controlli di autorizzazione personalizzati. Function2ha una fonte di dati DynamoDB collegata per interrogare la reviews tabella.

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

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

Gestione dei conflitti tra resolver su tipi condivisi

Consideriamo il caso seguente in cui implementiamo anche un resolver attivo Query.getPost per fornire più campi contemporaneamente oltre al field resolver in. Source2 Source1.graphqlpuò 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.graphqlpuò 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 modello di risoluzione dei campi che richiederebbe l'aggiunta di un tipo separato che definisca i campi di sua proprietà rispetto Source2.graphql al tipo. Post Nel seguente esempio, aggiungiamo un tipo chiamatoPostInfo, che contiene i campi content e author che verranno risolti da. Source2.graphql Source1.graphqlimplementerà il resolver collegato aQuery.getPost, mentre ora Source2.graphql collegherà un resolver per Post.postInfo garantire che tutti i dati possano essere recuperati correttamente:

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 a tutti i team di origine.

Gestione delle autorizzazioni sui campi condivisi

Quando due o più API di origine dichiarano lo stesso campo, l'unione combina le direttive di autorizzazione di ciascuna dichiarazione. I client possono quindi raggiungere il campo unito tramite una qualsiasi di queste modalità di autorizzazione. Se un'API di origine dichiara un campo con @aws_iam e un'altra API di origine dichiara lo stesso campo con@aws_api_key, il campo unito accetta entrambi e un client che contiene solo una chiave API può richiamarla.

Per mantenere l'autorizzazione di un campo così come la definisce l'API di origine, annota il campo con @canonical e dichiara la direttiva di autorizzazione richiesta sul campo stesso. Nel seguente esempio, Source1.graphql possiede il resolver per protectedRead e richiede l'autorizzazione 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 si verifica l'unione, la definizione di Source1.graphql:

# This snippet represents a file called MergedSchema.graphql

type Query {
    protectedRead: String @aws_iam
}

Senza l'annotazione @canonical, il campo unito sarebbe. protectedRead: String @aws_api_key @aws_iam Un client che detiene solo la chiave API dell'API unita può quindi richiamarla.

Se la tua API di origine possiede il resolver del campo, annota il campo in quell'API di origine, perché il suo resolver restituisce i dati.

Si applicano due condizioni:

Dichiarare la direttiva di autorizzazione sul campo

@canonical conserva il campo come dichiarato. Un campo annotato @canonical senza una propria direttiva di autorizzazione utilizza la modalità di autorizzazione principale dell'API di origine, che potrebbe essere più permissiva di quanto intendi.

Annota un campo in una sola API di origine

Se due API di origine annotano lo stesso campo come canonical, l'unione ha esito negativo e viene generato l'errore. Multiple subschemas cannot declare the same field as canonical

Applica @canonical a livello di campo anziché a livello di tipo per limitare l'autorizzazione su campi specifici. Ciò consente comunque ad altre API di origine di aggiungere campi aggiuntivi dello stesso tipo. Questa guida si applica ai campi su QueryMutation, e Subscription anche ai campi sui tipi di oggetto.

Se non vuoi affatto che un campo appaia nella Merged API, usa invece @hidden. Per ulteriori informazioni, consulta Direttive dello schema API unito.

Configurazione degli schemi

Due parti sono responsabili della configurazione degli schemi per creare un'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 dal tuo 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 la tua Merged API. Per saperne di più sulle modalità di autorizzazione in AWS AppSync, consulta Autorizzazione e autenticazione.

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

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 primaria configurata su un'API di origine come modalità di autorizzazione primaria propria o come modalità di autorizzazione secondaria. In caso contrario, sarà incompatibile e l'operazione di unione avrà esito negativo e si verificherà 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 primaria dell'API di origine non corrisponda alla modalità di autorizzazione primaria 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 crei un'API unita, devi definire un ruolo di servizio. Un ruolo AWS di servizio è un ruolo di AWS Identity and Access Management (IAM) utilizzato dai AWS servizi per eseguire attività per conto dell'utente.

In questo contesto, è necessario che la tua Merged API esegua resolver che accedono ai dati dalle origini dati configurate nelle API di origine. Il ruolo di servizio richiesto a tale scopo è ilmergedApiExecutionRole, che deve avere un accesso esplicito per eseguire le 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 AppSync supporta l'autorizzazione o la negazione di questa autorizzazione su specifici campi di primo livello all'interno della richiesta, ad esempio come funziona la modalità di autorizzazione IAM per le API IAM. Per i campi non di primo livello, AWS AppSync richiede di definire l'autorizzazione sull'ARN dell'API di origine stessa. Per limitare l'accesso a campi specifici non di primo livello nell'API Merged, ti consigliamo di implementare una logica personalizzata all'interno di Lambda o di nascondere i campi dell'API di origine dall'API unita 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 di seguito. Nota che la prima voce della 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:

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

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

Puoi anche utilizzare la procedura guidata di creazione dell'API della AWS AppSync console per generare un ruolo di servizio che consenta alla tua 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 siano nello stesso account dell'API unita, devi prima condividere le tue risorse utilizzando AWS Resource Access Manager ().AWS RAM

Configurazione delle API unite tra più account utilizzando AWS RAM

Quando crei un'API unita, puoi facoltativamente associare le API di origine di altri account che sono stati condivisi tramite Resource Access Manager (). AWS AWS RAM AWS RAM ti 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 AppSync si integra per supportare la configurazione e l'accesso alle API di origine su più account da un'unica API unita. AWS RAM AWS RAM consente di creare una condivisione di risorse o un contenitore di risorse e i set di autorizzazioni che verranno condivisi per ciascuna di esse. È possibile aggiungere AWS AppSync API a una condivisione di risorse in AWS RAM. All'interno di una condivisione di risorse, AWS AppSync fornisce tre diversi set di autorizzazioni che possono essere associati a un' AWS AppSync API nella RAM:

AWS AppSync supporta anche le autorizzazioni gestite dal cliente. Quando una delle autorizzazioni AWS gestite fornite non funziona, puoi creare la tua autorizzazione gestita dal cliente. Customer-managed le autorizzazioni sono autorizzazioni gestite che crei e gestisci specificando con precisione quali azioni possono essere eseguite in quali condizioni con le risorse condivise. AWS RAM AWS AppSync ti consente di scegliere tra le seguenti azioni quando crei la tua autorizzazione:

Una volta che hai condiviso correttamente un'API di origine o un'API unita AWS RAM e, se necessario, l'invito alla condivisione delle risorse è stato accettato, sarà visibile nella AWS AppSync console quando crei o aggiorni le associazioni dell'API di origine sulla tua API unita. Puoi anche elencare tutte le AWS AppSync API che sono state condivise utilizzando AWS RAM il tuo account indipendentemente dalle autorizzazioni impostate richiamando l'ListGraphqlApisoperazione fornita da AWS AppSync e utilizzando il OTHER_ACCOUNTS filtro proprietario.

Fusione

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 il AWS AppSync servizio gestisce l'integrazione delle risorse nel singolo endpoint Merged API per ridurre l'attrito nella collaborazione e ridurre i tempi di sviluppo.

Auto-merges

Le API di origine associate alla tua AWS AppSync Merged API possono essere configurate per unirsi automaticamente (unione automatica) nell'API Merged dopo aver apportato eventuali 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 unione con una definizione esistente nell'API unita. Se l'aggiornamento nell'API di origine aggiorna 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 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' AWS SDK 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 dopo l'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 il supporto integrato per gli abbonamenti GraphQL. Tutte le operazioni di sottoscrizione definite nelle API di origine associate verranno automaticamente unite e funzioneranno nella tua API unita senza modifiche. Per saperne di più su come AWS AppSync supporta gli abbonamenti tramite connessione serverless WebSockets , consulta i dati. Real-time

Configurazione dell'osservabilità

AWS AppSync Le API unite forniscono registrazione, monitoraggio e metriche integrati tramite Amazon. CloudWatch AWS AppSync fornisce anche un supporto integrato per il tracciamento tramite. AWS X-Ray

Configurazione di domini personalizzati

AWS AppSync Le API unite forniscono un supporto integrato per l'utilizzo di domini personalizzati con GraphQL e gli endpoint dell'API unita. Real-time

Configurazione della memorizzazione nella cache

AWS AppSync Le API unite forniscono un supporto integrato per la memorizzazione facoltativa nella cache delle risposte a livello di resolver a livello di richiesta e per la compressione and/or delle risposte. Per saperne di più, consulta Memorizzazione nella cache e compressione.

Configurazione di API private

AWS AppSync Le API unite forniscono il supporto integrato per le API private che limitano l'accesso a GraphQL e agli endpoint della tua API unita al traffico proveniente dagli Real-time endpoint VPC che puoi configurare. https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html

Configurazione delle regole del firewall

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

Configurazione dei log di controllo

AWS AppSync Le 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 le API unite, prendi nota delle seguenti regole:

Considerazioni sulle API unite

Durante la progettazione e l'implementazione delle API unite, considera quanto segue:

L'unione di più API di origine in un unico endpoint può aumentare le dimensioni e la complessità dello schema e delle query GraphQL. Man mano che lo schema unito cresce, potrebbe essere necessario utilizzare più resolver per soddisfare una singola richiesta, il che può aumentare la latenza del tempo complessivo di richiesta. Ad esempio, una query che accede a campi da più API di origine potrebbe richiedere l'esecuzione di resolver da ciascuna API di origine AWS AppSync in sequenza, con ogni resolver che si aggiunge al tempo di risposta totale.

Ti consigliamo vivamente di testare accuratamente le tue API unite durante lo sviluppo e in condizioni di carico realistiche per assicurarti che soddisfino i requisiti aziendali. Presta particolare attenzione a:

Prendi in considerazione l'implementazione di ottimizzazioni delle prestazioni come il caching, il batch delle richieste di origine dati e la progettazione degli schemi delle API di origine per ridurre al minimo il numero di esecuzioni del resolver necessarie per le operazioni comuni.

Creazione di API unite

Per creare un'API unita nella console