Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menggabungkan API di AWS AppSync

Ketika penggunaan GraphQL berkembang dalam suatu organisasi, pertukaran antara kemudahan penggunaan API dan kecepatan pengembangan API dapat muncul. Di satu sisi, organisasi mengadopsi AWS AppSync dan GraphQL untuk menyederhanakan pengembangan aplikasi. Ini memberi pengembang API fleksibel yang dapat mereka gunakan untuk mengakses, memanipulasi, dan menggabungkan data dengan aman dari satu atau lebih domain data dengan satu panggilan jaringan. Di sisi lain, tim dalam organisasi yang bertanggung jawab atas domain data yang berbeda yang digabungkan menjadi satu titik akhir GraphQL API mungkin menginginkan kemampuan untuk membuat, mengelola, dan menyebarkan pembaruan API secara independen satu sama lain. Ini meningkatkan kecepatan perkembangannya.

Untuk mengatasi ketegangan ini, fitur Gabungan API memungkinkan tim dari domain data yang berbeda untuk secara independen membuat dan menerapkan AWS AppSync API (misalnya, skema GraphQL, resolver, sumber data, dan fungsi), yang kemudian dapat AWS AppSync digabungkan menjadi satu API gabungan. Ini memberi organisasi kemampuan untuk mempertahankan API lintas domain yang mudah digunakan, dan cara bagi tim yang berbeda yang berkontribusi pada API itu kemampuan untuk membuat pembaruan API dengan cepat dan mandiri.

Diagram berikut menunjukkan alur kerja API gabungan:

Dengan menggunakan Gabungan API, organisasi dapat mengimpor sumber daya dari beberapa AWS AppSync API sumber independen ke dalam satu titik AWS AppSync akhir API Gabungan. Untuk melakukan ini, AWS AppSync memungkinkan Anda membuat daftar AWS AppSync API sumber, dan kemudian menggabungkan semua metadata yang terkait dengan API sumber termasuk skema, tipe, sumber data, resolver, dan fungsi, ke dalam API gabungan baru AWS AppSync .

Selama penggabungan, ada kemungkinan konflik penggabungan akan terjadi karena inkonsistensi dalam konten data API sumber seperti konflik penamaan tipe saat menggabungkan beberapa skema. Untuk kasus penggunaan sederhana di mana tidak ada definisi dalam API sumber yang bertentangan, tidak perlu memodifikasi skema API sumber. Gabungan API yang dihasilkan hanya mengimpor semua jenis, resolver, sumber data, dan fungsi dari AWS AppSync API sumber asli. Untuk kasus penggunaan yang kompleks di mana konflik muncul, users/teams akan harus menyelesaikan konflik melalui berbagai cara. AWS AppSync menyediakan pengguna dengan beberapa alat dan contoh yang dapat mengurangi konflik penggabungan.

Penggabungan berikutnya yang dikonfigurasi AWS AppSync akan menyebarkan perubahan yang dibuat di API sumber ke API Gabungan terkait.

Gabungan API dan Federasi

Ada banyak solusi dan pola di komunitas GraphQL untuk menggabungkan skema GraphQL dan memungkinkan kolaborasi tim melalui grafik bersama. AWS AppSync API yang digabungkan mengadopsi pendekatan waktu pembuatan untuk komposisi skema, di mana API sumber digabungkan menjadi API Gabungan yang terpisah. Pendekatan alternatif adalah melapisi router waktu proses di beberapa API sumber atau sub-grafik. Dalam pendekatan ini, router menerima permintaan, mereferensikan skema gabungan yang dipelihara sebagai metadata, membangun rencana permintaan, dan kemudian mendistribusikan elemen permintaan di seluruh sub- graphs/servers yang mendasarinya. Tabel berikut membandingkan pendekatan build- AWS AppSync time API yang digabungkan dengan pendekatan run-time berbasis router untuk komposisi skema GraphQL:

* AWS AppSync API gabungan hanya dapat dikaitkan dengan API AWS AppSync sumber. Jika Anda memerlukan dukungan untuk komposisi skema di seluruh AWS AppSync dan non-AWS AppSync sub-grafik, Anda dapat menghubungkan satu atau beberapa API Gabungan AWS AppSync GraphQL and/or ke dalam solusi berbasis router. Misalnya, lihat blog referensi untuk menambahkan AWS AppSync API sebagai sub-grafik menggunakan arsitektur berbasis router dengan Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync

Resolusi konflik API yang digabungkan

Jika terjadi konflik penggabungan, AWS AppSync berikan pengguna beberapa alat dan contoh untuk membantu memecahkan masalah.

Arahan skema API yang digabungkan

AWS AppSync telah memperkenalkan beberapa arahan GraphQL yang dapat digunakan untuk mengurangi atau menyelesaikan konflik di seluruh API sumber:

Untuk menampilkan arahan skema utilitas yang disediakan, pertimbangkan contoh berikut:

Dalam contoh ini, mari kita asumsikan bahwa kita ingin menggabungkan dua API sumber. Kami diberi dua skema yang membuat dan mengambil posting (misalnya, bagian komentar atau posting media sosial). Dengan asumsi bahwa jenis dan bidangnya sangat mirip, ada kemungkinan besar konflik selama operasi penggabungan. Cuplikan di bawah ini menunjukkan jenis dan bidang dari setiap skema.

File pertama, disebut Source1.graphql, adalah skema GraphQL yang memungkinkan pengguna untuk membuat Posts menggunakan putPost mutasi. Masing-masing Post berisi judul dan ID. ID digunakan untuk mereferensi User kan, atau informasi poster (email dan alamat), danMessage, atau muatan (konten). Ti User pe tersebut dianotasi dengan 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
}

File kedua, yang disebut Source2.graphql, adalah skema GraphQL yang melakukan hal-hal yang sangat mirip seperti Source1.graphql. Namun, perhatikan bahwa bidang dari setiap jenis berbeda. Saat menggabungkan kedua skema ini, akan ada konflik penggabungan karena perbedaan ini.

Perhatikan juga bagaimana Source2.graphql juga berisi beberapa arahan untuk mengurangi konflik ini. Tipe Post tersebut dianotasi dengan tag @hidden untuk mengaburkan dirinya sendiri selama operasi penggabungan. Ti Message pe tersebut dianotasi dengan tag @renamed untuk memodifikasi nama tipe ChatMessage jika terjadi konflik penamaan dengan tipe lainMessage.

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

Ketika penggabungan terjadi, hasilnya akan menghasilkan MergedSchema.graphql file:

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

Beberapa hal terjadi dalam penggabungan:

Ada juga kasus tidak ada arahan yang ditambahkan ke tipe yang bertentangan. Di sini, tipe gabungan akan menyertakan penyatuan semua bidang dari semua definisi sumber dari jenis itu. Misalnya, pertimbangkan contoh berikut:

Skema ini Source1.graphql, disebut, memungkinkan untuk membuat dan mengambil. Posts Konfigurasi mirip dengan contoh sebelumnya, tetapi dengan lebih sedikit informasi.

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

Skema ini Source2.graphql, disebut, memungkinkan untuk membuat dan mengambil Reviews (misalnya, peringkat film atau ulasan restoran). Reviewsdikaitkan dengan Post nilai ID yang sama. Bersama-sama, mereka berisi judul, ID posting, dan pesan muatan dari posting ulasan lengkap.

Saat menggabungkan, akan ada konflik antara kedua Post jenis tersebut. Karena tidak ada anotasi untuk menyelesaikan masalah ini, perilaku defaultnya adalah melakukan operasi penyatuan pada tipe yang saling bertentangan.

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

Ketika penggabungan terjadi, hasilnya akan menghasilkan MergedSchema.graphql file:

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

Beberapa hal terjadi dalam penggabungan:

Mengelola resolver pada tipe bersama

Dalam contoh di atas, pertimbangkan kasus di mana Source1.graphql telah mengkonfigurasi unit resolverQuery.getPost, yang menggunakan sumber data DynamoDB bernama. PostDatasource Resolver ini akan mengembalikan id dan title dari sebuah Post tipe. Sekarang, pertimbangkan Source2.graphql telah mengkonfigurasi resolver pipelinePost.reviews, yang menjalankan dua fungsi. Function1memiliki sumber None data yang dilampirkan untuk melakukan pemeriksaan otorisasi kustom. Function2memiliki sumber data DynamoDB yang dilampirkan untuk menanyakan tabel. reviews

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

Ketika kueri di atas dijalankan oleh klien ke titik akhir API Gabungan, AWS AppSync layanan pertama-tama menjalankan unit resolver untuk Query.getPost fromSource1, yang memanggil PostDatasource dan mengembalikan data dari DynamoDB. Kemudian, ia menjalankan resolver Post.reviews pipeline yang Function1 melakukan logika otorisasi khusus dan Function2 mengembalikan ulasan yang diberikan yang id ditemukan di$context.source. Layanan memproses permintaan sebagai satu proses GraphQL, dan permintaan sederhana ini hanya akan memerlukan satu token permintaan.

Mengelola konflik resolver pada tipe bersama

Pertimbangkan kasus berikut di mana kami juga mengimplementasikan resolver untuk menyediakan beberapa bidang sekaligus di luar penyelesai bidang di. Query.getPost Source2 Source1.graphqlmungkin terlihat seperti ini:

# This snippet represents a file called Source1.graphql

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

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

Source2.graphqlmungkin terlihat seperti ini:

# This snippet represents a file called Source2.graphql

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

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

Mencoba menggabungkan kedua skema ini akan menghasilkan kesalahan penggabungan karena API yang AWS AppSync digabungkan tidak mengizinkan beberapa resolver sumber dilampirkan ke bidang yang sama. Untuk menyelesaikan konflik ini, Anda dapat mengimplementasikan pola penyelesai bidang yang akan memerlukan Source2.graphql untuk menambahkan tipe terpisah yang akan menentukan bidang yang dimilikinya dari Post tipe tersebut. Dalam contoh berikut, kita menambahkan tipe yang disebutPostInfo, yang berisi bidang konten dan penulis yang akan diselesaikan oleh Source2.graphql. Source1.graphqlakan mengimplementasikan resolver yang dil Query.getPost ampirkan, sementara sekarang Source2.graphql akan melampirkan resolver Post.postInfo untuk memastikan bahwa semua data dapat berhasil diambil:

type Post  {
  id: ID!
  postInfo: PostInfo
}

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

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

Meskipun menyelesaikan konflik semacam itu memerlukan skema API sumber untuk ditulis ulang dan, berpotensi, klien untuk mengubah kueri mereka, keuntungan dari pendekatan ini adalah bahwa kepemilikan resolver gabungan tetap jelas di seluruh tim sumber.

Mengelola otorisasi pada bidang bersama

Ketika dua atau lebih API sumber mendeklarasikan bidang yang sama, penggabungan menggabungkan arahan otorisasi dari setiap deklarasi. Klien kemudian dapat mencapai bidang gabungan melalui salah satu mode otorisasi tersebut. Jika satu API sumber mendeklarasikan bidang dengan @aws_iam dan API sumber lain mendeklarasikan bidang yang sama dengan@aws_api_key, bidang gabungan menerimanya, dan klien yang hanya memegang kunci API dapat memanggilnya.

Untuk mempertahankan otorisasi bidang seperti yang didefinisikan oleh API sumber Anda, beri anotasi bidang dengan @canonical dan nyatakan direktif otorisasi yang Anda perlukan di bidang itu sendiri. Dalam contoh berikut, Source1.graphql memiliki resolver untuk protectedRead dan memerlukan otorisasi 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
}

Ketika penggabungan terjadi, definisi dari diut Source1.graphql amakan:

# This snippet represents a file called MergedSchema.graphql

type Query {
    protectedRead: String @aws_iam
}

Tanpa an otasi @canonical, bidang gabungan akan menjadiprotectedRead: String @aws_api_key @aws_iam. Klien yang hanya memegang kunci API Gabungan API kemudian dapat memanggilnya.

Jika API sumber Anda memiliki resolver bidang, beri anotasi bidang di API sumber tersebut, karena resolvernya mengembalikan data.

Dua kondisi berlaku:

Menyatakan arahan otorisasi di lapangan

@canonical mempertahankan bidang seperti yang dideklarasikan. Bidang beranotasi @canonical tanpa arahan otorisasi sendiri mengambil mode otorisasi utama API sumber Anda, yang mungkin lebih permisif daripada yang Anda inginkan.

Anotasi bidang hanya dalam satu API sumber

Jika dua API sumber membuat anotasi bidang yang sama dengan kanonik, penggabungan gagal dengan kesalahan. Multiple subschemas cannot declare the same field as canonical

Terapkan @canonical di tingkat bidang daripada tingkat tipe untuk membatasi otorisasi pada bidang tertentu. Ini masih memungkinkan API sumber lain untuk menyumbangkan bidang tambahan ke jenis yang sama. Panduan ini berlaku untuk bidang pada QueryMutation,, dan Subscription juga bidang pada tipe objek.

Jika Anda tidak ingin bidang muncul di API Gabungan sama sekali, gunakan @hidden sebagai gantinya. Untuk informasi selengkapnya, lihat Arahan skema API yang digabungkan.

Mengkonfigurasi skema

Dua pihak bertanggung jawab untuk mengonfigurasi skema untuk membuat API Gabungan:

Karena skema Gabungan API dibuat dari skema API sumber terkait, skema ini hanya bisa di baca. Ini berarti perubahan pada skema harus dimulai di API sumber Anda. Di AWS AppSync konsol, Anda dapat beralih antara skema Gabungan dan skema individual dari API sumber yang disertakan dalam API Gabungan menggunakan daftar drop-down di atas jendela Skema.

Mengkonfigurasi mode otorisasi

Beberapa mode otorisasi tersedia untuk melindungi API Gabungan Anda. Untuk mempelajari lebih lanjut tentang mode otorisasi di AWS AppSync, lihat Otor isasi dan otentikasi.

Mode otorisasi berikut tersedia untuk digunakan dengan Gabungan API:

Mode otorisasi API Gabungan dikonfigurasi oleh pemilik API Gabungan. Pada saat operasi penggabungan, API Gabungan harus menyertakan mode otorisasi utama yang dikonfigurasi pada API sumber baik sebagai mode otorisasi utamanya sendiri atau sebagai mode otorisasi sekunder. Jika tidak, itu akan tidak kompatibel, dan operasi penggabungan akan gagal dengan konflik. Saat menggunakan arahan multi-auth di API sumber, proses penggabungan dapat secara otomatis menggabungkan arahan ini ke titik akhir terpadu. Dalam kasus di mana mode otorisasi utama dari API sumber tidak cocok dengan mode otorisasi utama dari API Gabungan, itu akan secara otomatis menambahkan arahan autentikasi ini untuk memastikan bahwa mode otorisasi untuk tipe di API sumber konsisten.

Mengkonfigurasi peran eksekusi

Saat Anda membuat API Gabungan, Anda perlu menentukan peran layanan. Peran AWS layanan adalah peran AWS Identitas dan Manajemen Akses (IAM) yang digunakan oleh AWS layanan untuk melakukan tugas atas nama Anda.

Dalam konteks ini, API Gabungan Anda perlu menjalankan resolver yang mengakses data dari sumber data yang dikonfigurasi di API sumber Anda. Peran layanan yang diperlukan untuk ini adalahmergedApiExecutionRole, dan harus memiliki akses eksplisit untuk menjalankan permintaan pada API sumber yang disertakan dalam API gabungan Anda melalui izin appsync:SourceGraphQL IAM. Selama menjalankan permintaan GraphQL, AWS AppSync layanan akan mengambil peran layanan ini dan mengotorisasi peran untuk melakukan tindakan. appsync:SourceGraphQL

AWS AppSync mendukung mengizinkan atau menolak izin ini pada bidang tingkat atas tertentu dalam permintaan seperti cara kerja mode otorisasi IAM untuk API IAM. Untuk bidang non-tingkat atas, AWS AppSync mengharuskan Anda untuk menentukan izin pada ARN API sumber itu sendiri. Untuk membatasi akses ke bidang non-tingkat atas tertentu di Gabungan API, sebaiknya terapkan logika kustom dalam Lambda Anda atau menyembunyikan bidang API sumber dari API Gabungan menggunakan direktif @hidden. Jika Anda ingin mengizinkan peran untuk melakukan semua operasi data dalam API sumber, Anda dapat menambahkan kebijakan di bawah ini. Perhatikan bahwa entri sumber daya pertama memungkinkan akses ke semua bidang tingkat atas dan entri kedua mencakup penyelesai anak yang mengotorisasi pada sumber daya API sumber itu sendiri:

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

Jika Anda ingin membatasi akses hanya ke bidang tingkat atas tertentu, Anda dapat menggunakan kebijakan seperti ini:

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

Anda juga dapat menggunakan wizard pembuatan API AWS AppSync konsol untuk membuat peran layanan agar API Gabungan mengakses sumber daya yang dikonfigurasi dalam API sumber yang berada di akun yang sama dengan API gabungan Anda. Jika API sumber Anda tidak berada di akun yang sama dengan API gabungan, Anda harus terlebih dahulu membagikan sumber daya menggunakan AWS Resource Access Manager (AWS RAM).

Mengkonfigurasi API Gabungan lintas akun menggunakan AWS RAM

Saat membuat API Gabungan, Anda dapat secara opsional mengaitkan API sumber dari akun lain yang telah dibagikan melalui AWS Resource Access Manager (AWS RAM). AWS RAM membantu Anda berbagi sumber daya dengan aman di seluruh AWS akun, di dalam organisasi atau unit organisasi (OU) Anda, dan dengan peran dan pengguna IAM.

AWS AppSync terintegrasi AWS RAM dengan untuk mendukung konfigurasi dan mengakses API sumber di beberapa akun dari satu API Gabungan. AWS RAM memungkinkan Anda untuk membuat berbagi sumber daya, atau wadah sumber daya dan kumpulan izin yang akan dibagikan untuk masing-masing sumber daya. Anda dapat menambahkan AWS AppSync API ke berbagi sumber daya di AWS RAM. Dalam pembagian sumber daya, AWS AppSync menyediakan tiga set izin berbeda yang dapat dikaitkan dengan AWS AppSync API di RAM:

AWS AppSync juga mendukung izin yang dikelola pelanggan. Jika salah satu izin yang AWS dikelola tidak berfungsi, Anda dapat membuat izin yang dikelola pelanggan Anda sendiri. Customer-managed izin adalah izin terkelola yang Anda buat dan pertahankan dengan menentukan secara tepat tindakan mana yang dapat dilakukan dalam kondisi apa dengan sumber daya yang digunakan bersama AWS RAM. AWS AppSync memungkinkan Anda untuk memilih dari tindakan berikut saat membuat izin Anda sendiri:

Setelah Anda membagikan API sumber atau API Gabungan dengan benar AWS RAM dan, jika perlu, undangan berbagi sumber daya telah diterima, undangan tersebut akan terlihat di AWS AppSync konsol saat Anda membuat atau memperbarui asosiasi API sumber di API Gabungan Anda. Anda juga dapat mencant AWS AppSync umkan semua API yang telah digunakan bersama AWS RAM dengan akun Anda terlepas dari izin yang ditetapkan dengan memanggil ListGraphqlApis operasi yang disediakan oleh AWS AppSync dan menggunakan filter OTHER_ACCOUNTS pemilik.

Penggabungan

Mengelola merger

API gabungan dimaksudkan untuk mendukung kolaborasi tim pada titik AWS AppSync akhir terpadu. Tim dapat secara mandiri mengembangkan API GraphQL sumber terisolasi mereka sendiri di backend sementara AWS AppSync layanan mengelola integrasi sumber daya ke dalam titik akhir API Gabungan tunggal untuk mengurangi gesekan dalam kolaborasi dan mengurangi waktu tunggu pengembangan.

Auto-merges

API Sumber yang terkait dengan API AWS AppSync Gabungan Anda dapat dikonfigurasi untuk secara otomatis menggabungkan (penggabungan otomatis) ke API Gabungan setelah perubahan dilakukan pada API sumber. Ini memastikan bahwa perubahan dari API sumber selalu disebarkan ke titik akhir API Gabungan di latar belakang. Setiap perubahan dalam skema API sumber akan diperbarui di Gabungan API selama tidak menimbulkan konflik penggabungan dengan definisi yang ada di API Gabungan. Jika pembaruan di API sumber memperbarui resolver, sumber data, atau fungsi, sumber daya yang diimpor juga akan diperbarui.Ketika konflik baru diperkenalkan yang tidak dapat diselesaikan secara otomatis (diselesaikan secara otomatis), pembaruan skema API Gabungan ditolak karena konflik yang tidak didukung selama operasi penggabungan. Pesan kesalahan tersedia di konsol untuk setiap asosiasi API sumber yang memiliki statusMERGE_FAILED. Anda juga dapat memeriksa pesan kesalahan dengan memanggil GetSourceApiAssociation operasi untuk asosiasi API sumber tertentu menggunakan AWS SDK atau menggunakan AWS CLI seperti ini:

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

Ini akan menghasilkan hasil dalam format berikut:

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

Penggabungan manual

Pengaturan default untuk API sumber adalah penggabungan manual. Untuk menggabungkan perubahan apa pun yang telah terjadi di API sumber sejak API Gabungan terakhir diperbarui, pemilik API sumber dapat memanggil penggabungan manual dari AWS AppSync konsol atau melalui StartSchemaMerge operasi yang tersedia di AWS SDK dan AWS CLI.

Dukungan tambahan untuk API Gabungan

Mengkonfigurasi langganan

Tidak seperti pendekatan berbasis router untuk komposisi skema GraphQL, Gabungan API AWS AppSync menyediakan dukungan bawaan untuk langganan GraphQL. Semua operasi langganan yang ditentukan dalam API sumber terkait Anda akan secara otomatis bergabung dan berfungsi di API Gabungan Anda tanpa modifikasi. Untuk mempelajari selengkapnya tentang cara AWS AppSync mendukung langganan melalui WebSockets koneksi tanpa server, lihat Real-time data.

Mengkonfigurasi observabilitas

AWS AppSync API gabungan menyediakan pencatatan, pemantauan, dan metrik bawaan melalui Amazon CloudWatch. AWS AppSync juga menyediakan dukungan bawaan untuk pelacakan melalui AWS X-Ray.

Mengkonfigurasi domain khusus

AWS AppSync API yang digabungkan menyediakan dukungan bawaan untuk menggunakan domain khusus dengan GraphQL dan titik akhir API Gabungan Anda Real-time .

Mengkonfigurasi caching

AWS AppSync API gabungan menyediakan dukungan bawaan untuk caching respons tingkat and/or resolver tingkat permintaan secara opsional serta kompresi respons. Untuk mempelajari lebih lanjut, lihat Caching dan kompresi.

Mengkonfigurasi API pribadi

AWS AppSync API gabungan menyediakan dukungan bawaan untuk API Pribadi yang membatasi akses ke GraphQL dan titik akhir API Gabungan Anda ke lalu lintas yang berasal dari Real-time titik akhir VPC yang dapat Anda konfigurasikan.

Mengkonfigurasi aturan firewall

AWS AppSync API gabungan menyediakan dukungan bawaan untuk AWS WAF, yang memungkinkan Anda melindungi API dengan menentukan aturan firewall aplikasi web.

Mengkonfigurasi log audit

AWS AppSync API gabungan menyediakan dukungan bawaan untuk AWS CloudTrail, yang memungkinkan Anda mengonfigurasi dan mengelola log audit.

Batasan API yang digabungkan

Saat mengembangkan API Gabungan, perhatikan aturan berikut:

Pertimbangan API yang digabungkan

Saat merancang dan menerapkan API Gabungan, pertimbangkan hal berikut:

Menggabungkan beberapa API sumber ke dalam satu titik akhir dapat meningkatkan ukuran dan kompleksitas skema dan kueri GraphQL Anda. Seiring pertumbuhan skema gabungan Anda, kueri mungkin perlu melintasi beberapa resolver untuk memenuhi satu permintaan, yang dapat menambahkan latensi ke waktu permintaan Anda secara keseluruhan. Misalnya, kueri yang mengakses bidang dari beberapa API sumber mungkin memerlukan AWS AppSync untuk mengeksekusi resolver dari setiap API sumber secara berurutan, dengan setiap resolver menambah waktu respons total.

Kami sangat menyarankan Anda menguji API Gabungan secara menyeluruh selama pengembangan dan dalam kondisi beban yang realistis untuk memastikan API tersebut memenuhi persyaratan bisnis Anda. Berikan perhatian khusus pada:

Pertimbangkan untuk menerapkan pengoptimalan kinerja seperti caching, batch permintaan sumber data, dan merancang skema API sumber Anda untuk meminimalkan jumlah eksekusi resolver yang diperlukan untuk operasi umum.

Membuat API Gabungan

Untuk membuat API Gabungan di konsol