Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Menggabungkan APIs AWS AppSync
Ketika penggunaan GraphQL meluas dalam suatu organisasi, trade-off API ease-of-use antara dan kecepatan pengembangan dapat muncul. API Di satu sisi, organisasi mengadopsi AWS AppSync dan GraphQL untuk menyederhanakan pengembangan aplikasi dengan memberi pengembang API fleksibilitas 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 digabungkan menjadi satu titik akhir API GraphQL mungkin menginginkan kemampuan untuk membuat, mengelola, dan API menyebarkan pembaruan secara independen satu sama lain untuk meningkatkan kecepatan pengembangan mereka.
Untuk mengatasi ketegangan ini, APIs fitur AWS AppSync Gabungan memungkinkan tim dari domain data yang berbeda untuk membuat dan menerapkan secara independen AWS AppSync APIs (misalnya, skema GraphQL, resolver, sumber data, dan fungsi), yang kemudian dapat digabungkan menjadi satu, digabungkan. API Ini memberi organisasi kemampuan untuk mempertahankan yang mudah digunakan, lintas domainAPI, dan cara bagi tim yang berbeda yang berkontribusi pada kemampuan untuk melakukan API pembaruan dengan cepat dan mandiri. API

Menggunakan MergedAPIs, organisasi dapat mengimpor sumber daya dari beberapa sumber independen AWS AppSync APIs ke dalam satu titik akhir AWS AppSync GabunganAPI. Untuk melakukan ini, AWS AppSync Anda dapat membuat daftar sumber AWS AppSync sumberAPIs, dan kemudian menggabungkan semua metadata yang terkait dengan sumber APIs termasuk skema, jenis, sumber data, resolver, dan fungsi, menjadi gabungan baru. AWS AppSync API
Selama penggabungan, ada kemungkinan konflik penggabungan akan terjadi karena ketidakkonsistenan dalam konten API data sumber seperti konflik penamaan tipe saat menggabungkan beberapa skema. Untuk kasus penggunaan sederhana di mana tidak ada definisi dalam APIs konflik sumber, tidak perlu memodifikasi API skema sumber. Hasil Gabungan API hanya mengimpor semua jenis, resolver, sumber data, dan fungsi dari sumber aslinya. AWS AppSync APIs Untuk kasus penggunaan kompleks di mana konflik muncul, pengguna/tim harus menyelesaikan konflik melalui berbagai cara. AWS AppSync memberi pengguna beberapa alat dan contoh yang dapat mengurangi konflik penggabungan.
Penggabungan berikutnya yang dikonfigurasi AWS AppSync akan menyebarkan perubahan yang dibuat di sumber APIs ke Gabungan terkait. API
Gabungan APIs dan Federasi
Ada banyak solusi dan pola dalam komunitas GraphQL untuk menggabungkan skema GraphQL dan memungkinkan kolaborasi tim melalui grafik bersama. AWS AppSync Gabungan APIs mengadopsi pendekatan waktu pembuatan untuk komposisi skema, di mana sumber APIs digabungkan menjadi terpisah, Digabungkan. API Pendekatan alternatif adalah melapisi router run time di beberapa sumber APIs atau sub-grafik. Dalam pendekatan ini, router menerima permintaan, mereferensikan skema gabungan yang dipertahankannya sebagai metadata, membuat rencana permintaan, dan kemudian mendistribusikan elemen permintaan di seluruh sub-grafik/server yang mendasarinya. Tabel berikut membandingkan pendekatan AWS AppSync API build-time Gabungan dengan pendekatan run-time berbasis router untuk komposisi skema GraphQL:
Fitur | AppSync Digabungkan API | Solusi berbasis router |
Sub-grafik dikelola secara independen | Ya | Ya |
Sub-grafik dapat dialamatkan secara independen | Ya | Ya |
Komposisi skema otomatis | Ya | Ya |
Deteksi konflik otomatis | Ya | Ya |
Resolusi konflik melalui arahan skema | Ya | Ya |
Server sub-grafik yang didukung | AWS AppSync* | Bervariasi |
Kompleksitas jaringan | Tunggal, digabungkan API berarti tidak ada hop jaringan tambahan. | Arsitektur multi-layer memerlukan perencanaan dan delegasi kueri, parsing sub-kueri dan serialisasi/deserialisasi, dan resolver referensi dalam sub-grafik untuk melakukan penggabungan. |
Dukungan observabilitas | Pemantauan, pencatatan, dan penelusuran bawaan. APIServer tunggal yang digabungkan berarti debugging yang disederhanakan. | Build-your-own observabilitas di seluruh router dan semua server sub-grafik terkait. Debugging kompleks di seluruh sistem terdistribusi. |
Dukungan otorisasi | Dibangun dalam dukungan untuk beberapa mode otorisasi. | Build-your-own aturan otorisasi. |
Keamanan lintas akun | Dukungan bawaan untuk asosiasi akun lintas AWS cloud. | Build-your-own model keamanan. |
Dukungan langganan | Ya | Tidak |
* AWS AppSync Gabungan hanya APIs dapat dikaitkan dengan AWS AppSync sumberAPIs. Jika Anda memerlukan dukungan untuk komposisi skema di seluruh AWS AppSync dan AWS AppSync non-sub-grafik, Anda dapat menghubungkan satu atau lebih GraphQL dan/atau Digabungkan menjadi AWS AppSync solusi berbasis router. APIs Misalnya, lihat blog referensi untuk menambahkan AWS AppSync APIs sebagai sub-grafik menggunakan arsitektur berbasis router dengan Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync
Topik
Resolusi API konflik yang digabungkan
Jika terjadi konflik penggabungan, AWS AppSync berikan beberapa alat dan contoh kepada pengguna untuk membantu memecahkan masalah.
Arahan API skema gabungan
AWS AppSync telah memperkenalkan beberapa arahan GraphQL yang dapat digunakan untuk- mengurangi atau menyelesaikan konflik di seluruh sumber: APIs
-
@canonical: Arahan ini menetapkan prioritas tipe/bidang dengan nama dan data yang serupa. Jika dua atau lebih sumber APIs memiliki tipe atau bidang GraphQL yang sama, salah satu sumber dapat membuat anotasi jenis atau bidangnya sebagai kanonik, yang akan diprioritaskan selama penggabungan. APIs Jenis/bidang yang bertentangan yang tidak dianotasi dengan arahan ini di sumber lain diabaikan saat digabungkan. APIs
-
@hidden: Arahan ini merangkum jenis/bidang tertentu untuk menghapusnya dari proses penggabungan. Tim mungkin ingin menghapus atau menyembunyikan jenis atau operasi tertentu di sumber API sehingga hanya klien internal yang dapat mengakses data tertentu yang diketik. Dengan direktif ini terlampir, jenis atau bidang tidak digabungkan ke dalam Gabungan. API
-
@renamed: Arahan ini mengubah nama jenis/bidang untuk mengurangi konflik penamaan. Ada situasi di mana berbeda APIs memiliki jenis atau nama bidang yang sama. Namun, semuanya harus tersedia dalam skema gabungan. Cara sederhana untuk memasukkan semuanya ke dalam Gabungan API adalah dengan mengganti nama bidang menjadi sesuatu yang serupa tetapi berbeda.
Untuk menunjukkan arahan skema utilitas yang disediakan, pertimbangkan contoh berikut:
Dalam contoh ini, mari kita asumsikan bahwa kita ingin menggabungkan dua sumberAPIs. Kami diberi dua skema yang membuat dan mengambil posting (misalnya, bagian komentar atau posting media sosial). Dengan asumsi bahwa tipe dan bidangnya sangat mirip, ada kemungkinan besar konflik selama operasi penggabungan. Cuplikan di bawah ini menunjukkan jenis dan bidang setiap skema.
File pertama, yang disebut Source1.graphQL, adalah skema GraphQL yang memungkinkan pengguna untuk membuat menggunakan mutasi. Posts
putPost
Masing-masing Post
berisi judul dan ID. ID digunakan untuk referensiUser
, atau informasi poster (email dan alamat), danMessage
, atau muatan (konten). User
Jenis ini 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 yang sangat mirip dengan Source1.graphQL. Namun, perhatikan bahwa bidang masing-masing 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. Post
Tipe ini dianotasi dengan tag @hidden untuk mengaburkan dirinya sendiri selama operasi penggabungan. Message
Tipe dianotasi dengan tag @renamed untuk memodifikasi nama tipe jika terjadi konflik penamaan dengan tipe lainMessage
. ChatMessage
# 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:
-
User
Jenis dari source1.graphQL diprioritaskan daripadaUser
from Source2.graphQL karena anotasi @canonical. -
Message
Jenis dari source1.graphQL disertakan dalam penggabungan. Namun,Message
from Source2.graphQL memiliki konflik penamaan. Karena anotasi @renamed, itu juga termasuk dalam penggabungan tetapi dengan nama alternatif.ChatMessage
-
Post
Jenis dari source1.graphQL disertakan, tetapiPost
tipe dari Source2.graphQL tidak. Biasanya, akan ada konflik pada tipe ini, tetapi karenaPost
tipe dari Source2.graphQL memiliki anotasi @hidden, datanya dikaburkan dan tidak termasuk dalam penggabungan. Hal ini mengakibatkan tidak ada konflik. -
Query
Jenis diperbarui untuk menyertakan konten dari kedua file. Namun, satuGetMessage
kueri diganti namanyaGetChatMessage
karena arahan. Ini menyelesaikan konflik penamaan antara dua kueri dengan nama yang sama.
Ada juga kasus tidak ada arahan yang ditambahkan ke tipe yang bertentangan. Di sini, tipe gabungan akan mencakup penyatuan semua bidang dari semua definisi sumber dari jenis itu. Misalnya, perhatikan contoh berikut:
Skema ini, yang disebut Source1.graphQL, memungkinkan untuk membuat dan mengambil. Posts
Konfigurasinya mirip dengan contoh sebelumnya, tetapi dengan informasi yang lebih sedikit.
# 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, yang disebut Source2.graphQL, memungkinkan untuk membuat dan mengambil Reviews
(misalnya, rating film atau ulasan restoran). Reviews
dikaitkan dengan Post
nilai ID yang sama. Bersama-sama, mereka berisi judul, ID posting, dan pesan payload dari posting ulasan lengkap.
Saat bergabung, akan ada konflik antara kedua Post
jenis tersebut. Karena tidak ada anotasi untuk mengatasi masalah ini, perilaku defaultnya adalah melakukan operasi gabungan pada tipe yang 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:
-
Mutation
Tipe tidak menghadapi konflik dan digabung. -
Bidang
Post
tipe digabungkan melalui operasi serikat pekerja. Perhatikan bagaimana penyatuan antara keduanya menghasilkan satuid
, satutitle
, dan satureviews
. -
Review
Tipe tidak menghadapi konflik dan digabung. -
Query
Tipe tidak menghadapi konflik dan digabung.
Mengelola resolver pada tipe bersama
Dalam contoh di atas, pertimbangkan kasus di mana Source1.graphQL telah mengkonfigurasi resolver unit, Query.getPost
yang menggunakan sumber data DynamoDB bernama. PostDatasource
Resolver ini akan mengembalikan id
dan dari title
tipe. Post
Sekarang, pertimbangkan Source2.graphQL telah mengonfigurasi resolver pipeline, yang menjalankan dua fungsi. Post.reviews
Function1
memiliki sumber None
data yang dilampirkan untuk melakukan pemeriksaan otorisasi khusus. Function2
memiliki 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 API titik akhir Gabungan, AWS AppSync layanan pertama menjalankan resolver unit untuk Query.getPost
fromSource1
, yang memanggil PostDatasource
dan mengembalikan data dari DynamoDB. Kemudian, ia menjalankan resolver Post.reviews
pipeline di mana Function1
melakukan logika otorisasi khusus dan Function2
mengembalikan ulasan yang diberikan yang ditemukan diid
. $context.source
Layanan memproses permintaan sebagai satu GraphQL run, dan permintaan sederhana ini hanya akan memerlukan satu token permintaan.
Mengelola konflik resolver pada tipe bersama
Pertimbangkan kasus berikut di mana kami juga menerapkan resolver untuk menyediakan beberapa bidang sekaligus di luar penyelesai bidang di. Query.getPost
Source2
source1.graphQL mungkin 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.graphQL mungkin 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 AWS AppSync penggabungan karena Gabungan APIs tidak mengizinkan beberapa resolver sumber dilampirkan ke bidang yang sama. Untuk mengatasi konflik ini, Anda dapat menerapkan pola penyelesai bidang yang memerlukan Source2.graphQL untuk menambahkan tipe terpisah yang akan menentukan bidang yang dimilikinya dari tipe tersebut. Post
Dalam contoh berikut, kami menambahkan tipe yang disebutPostInfo
, yang berisi bidang konten dan penulis yang akan diselesaikan oleh Source2.graphQL. Source1.graphQL akan mengimplementasikan resolver yang dilampirkanQuery.getPost
, sementara Source2.graphQL sekarang akan melampirkan resolver untuk memastikan bahwa semua data dapat berhasil diambil: Post.postInfo
type Post { id: ID! postInfo: PostInfo } type PostInfo { content: String! contentHash: String! author: String! } type Query { getPost(id: ID!): Post }
Sementara menyelesaikan konflik semacam itu membutuhkan API skema 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.
Mengkonfigurasi skema
Dua pihak bertanggung jawab untuk mengonfigurasi skema untuk membuat Gabungan: API
-
APIPemilik gabungan - API Pemilik gabungan harus mengonfigurasi logika otorisasi Gabungan API dan pengaturan lanjutan seperti logging, tracing, caching, dan dukungan. WAF
-
APIPemilik sumber terkait - API Pemilik terkait harus mengonfigurasi skema, resolver, dan sumber data yang membentuk Gabungan. API
Karena skema API Gabungan Anda dibuat dari skema sumber terkait AndaAPIs, skema tersebut hanya dibaca. Ini berarti perubahan skema harus dimulai di sumber Anda. APIs Di AWS AppSync konsol, Anda dapat beralih antara skema Gabungan dan skema individual sumber yang APIs disertakan dalam Gabungan API 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 AWS AppSync, lihat Otorisasi dan otentikasi.
Mode otorisasi berikut tersedia untuk digunakan dengan APIs Gabungan:
-
APIkunci: Strategi otorisasi paling sederhana. Semua permintaan harus menyertakan API kunci di bawah header
x-api-key
permintaan. APIKunci kedaluwarsa disimpan selama 60 hari setelah tanggal kedaluwarsa. -
AWS Identity and Access Management (IAM): Strategi AWS IAM otorisasi mengotorisasi semua permintaan yang ditandatangani sigv4.
-
Kumpulan Pengguna Amazon Cognito: Otorisasi pengguna Anda melalui Kumpulan Pengguna Amazon Cognito untuk mencapai kontrol yang lebih halus.
-
AWS Lambda Authorizers: Fungsi tanpa server yang memungkinkan Anda untuk mengautentikasi dan mengotorisasi akses ke logika kustom Anda menggunakan. AWS AppSync API
-
OpenID Connect: Jenis otorisasi ini memberlakukan token OpenID connect (OIDC) yang disediakan oleh layanan -compliant. OIDC Aplikasi Anda dapat memanfaatkan pengguna dan hak istimewa yang ditentukan oleh OIDC penyedia Anda untuk mengontrol akses.
Mode otorisasi Gabungan API dikonfigurasi oleh pemilik API Gabungan. Pada saat operasi gabungan, Gabungan API harus menyertakan mode otorisasi utama yang dikonfigurasi pada sumber API 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 sumberAPIs, proses penggabungan dapat secara otomatis menggabungkan arahan ini ke titik akhir terpadu. Dalam kasus di mana mode otorisasi utama sumber API tidak cocok dengan mode otorisasi utama GabunganAPI, itu akan secara otomatis menambahkan arahan autentikasi ini untuk memastikan bahwa mode otorisasi untuk jenis di sumber konsisten. API
Mengkonfigurasi peran eksekusi
Saat membuat GabunganAPI, Anda perlu menentukan peran layanan. Peran AWS layanan adalah peran AWS Identity and Access Management (IAM) yang digunakan oleh AWS layanan untuk melakukan tugas atas nama Anda.
Dalam konteks ini, Gabungan Anda API perlu menjalankan resolver yang mengakses data dari sumber data yang dikonfigurasi di sumber Anda. APIs Peran layanan yang diperlukan untuk ini adalahmergedApiExecutionRole
, dan harus memiliki akses eksplisit untuk menjalankan permintaan pada sumber yang APIs disertakan dalam gabungan Anda API 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 IAM otorisasi. IAM APIs Untuk non-top-level bidang, AWS AppSync mengharuskan Anda untuk menentukan izin pada sumber API ARN itu sendiri. Untuk membatasi akses ke non-top-level bidang tertentu di GabunganAPI, sebaiknya terapkan logika kustom dalam Lambda Anda atau menyembunyikan API bidang sumber dari direktif API Gabungan menggunakan @hidden. Jika Anda ingin mengizinkan peran menjalankan semua operasi data dalam sumberAPI, Anda dapat menambahkan kebijakan di bawah ini. Perhatikan bahwa entri sumber daya pertama memungkinkan akses ke semua bidang tingkat atas dan entri kedua mencakup resolver turunan yang mengotorisasi sumber daya itu sendiri: API
{ "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:
{ "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 API pembuatan AWS AppSync konsol untuk menghasilkan peran layanan agar Gabungan dapat mengakses sumber daya API yang dikonfigurasi di sumber APIs yang berada di akun yang sama dengan gabungan API Anda. Jika sumber Anda tidak APIs berada di akun yang sama dengan yang digabungkanAPI, Anda harus terlebih dahulu membagikan sumber daya menggunakan AWS Resource Access Manager (AWS RAM).
Mengkonfigurasi Cross-Account Merged menggunakan APIs AWS RAM
Saat membuat GabunganAPI, Anda dapat secara opsional mengaitkan sumber APIs 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, dalam organisasi atau unit organisasi Anda (OUs), dan dengan IAM peran dan pengguna.
AWS AppSync terintegrasi dengan AWS RAM untuk mendukung konfigurasi dan mengakses sumber APIs di beberapa akun dari satu Gabungan. API AWS RAM memungkinkan Anda membuat pembagian sumber daya, atau wadah sumber daya dan set izin yang akan dibagikan untuk masing-masing sumber daya. Anda dapat menambahkan AWS AppSync APIs ke pembagian sumber daya di AWS RAM. Dalam pembagian sumber daya, AWS AppSync berikan tiga set izin berbeda yang dapat dikaitkan dengan AWS AppSync API inRAM:
-
AWSRAMPermissionAppSyncSourceApiOperationAccess
: Set izin default yang ditambahkan saat berbagi AWS AppSync API in AWS RAM jika tidak ada izin lain yang ditentukan. Set izin ini digunakan untuk berbagi sumber AWS AppSync API dengan API pemilik Gabungan. Set izin ini mencakup izin untukappsync:AssociateMergedGraphqlApi
pada sumber API sertaappsync:SourceGraphQL
izin yang diperlukan untuk mengakses sumber API daya sumber saat runtime. -
AWSRAMPermissionAppSyncMergedApiOperationAccess
: Set izin ini harus dikonfigurasi saat berbagi Gabungan API dengan API pemilik sumber. Set izin ini akan memberi sumber API kemampuan untuk mengonfigurasi Gabungan API termasuk kemampuan untuk mengaitkan sumber apa pun yang APIs dimiliki oleh prinsipal target ke Gabungan API dan untuk membaca dan memperbarui API asosiasi sumber Gabungan. API -
AWSRAMPermissionAppSyncAllowSourceGraphQLAccess
: Set izin ini memungkinkanappsync:SourceGraphQL
izin untuk digunakan dengan file AWS AppSync API. Ini dimaksudkan untuk digunakan untuk berbagi sumber API dengan API pemilik Gabungan. Berbeda dengan izin default yang ditetapkan untuk akses API operasi sumber, set izin ini hanya menyertakan izinappsync:SourceGraphQL
runtime. Jika pengguna memilih untuk membagikan akses API operasi Gabungan ke API pemilik sumber, mereka juga perlu membagikan izin ini dari sumber API ke API pemilik Gabungan agar memiliki akses runtime melalui titik akhir Gabungan. API
AWS AppSync juga mendukung izin yang dikelola pelanggan. Jika salah satu izin AWS-managed yang disediakan tidak berfungsi, Anda dapat membuat izin yang dikelola pelanggan sendiri. Izin yang dikelola pelanggan adalah izin terkelola yang Anda buat dan pertahankan dengan menentukan secara tepat tindakan mana yang dapat dilakukan dalam kondisi mana dengan sumber daya yang digunakan bersama. AWS RAM AWS AppSync memungkinkan Anda memilih dari tindakan berikut saat membuat izin Anda sendiri:
-
appsync:AssociateSourceGraphqlApi
-
appsync:AssociateMergedGraphqlApi
-
appsync:GetSourceApiAssociation
-
appsync:UpdateSourceApiAssociation
-
appsync:StartSchemaMerge
-
appsync:ListTypesByAssociation
-
appsync:SourceGraphQL
Setelah Anda membagikan sumber API atau Digabungkan API 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 API asosiasi sumber pada API Gabungan Anda. Anda juga dapat mencantumkan semua AWS AppSync APIs yang telah AWS RAM dibagikan menggunakan akun Anda terlepas dari izin yang ditetapkan dengan memanggil ListGraphqlApis
operasi yang disediakan oleh AWS AppSync dan menggunakan filter OTHER_ACCOUNTS
pemilik.
catatan
Berbagi melalui AWS RAM memerlukan pemanggil AWS RAM untuk memiliki izin untuk melakukan appsync:PutResourcePolicy
tindakan pada apa pun API yang sedang dibagikan.
Penggabungan
Mengelola penggabungan
Gabungan APIs dimaksudkan untuk mendukung kolaborasi tim pada titik akhir terpadu AWS AppSync . Tim dapat secara mandiri mengembangkan APIs 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.
Penggabungan otomatis
Sumber APIs yang terkait dengan AWS AppSync Gabungan Anda API dapat dikonfigurasi untuk menggabungkan secara otomatis (penggabungan otomatis) ke dalam Gabungan API setelah perubahan apa pun dilakukan pada sumber. API Ini memastikan bahwa perubahan dari sumber selalu API disebarkan ke API titik akhir Gabungan di latar belakang. Setiap perubahan dalam API skema sumber akan diperbarui dalam Gabungan selama API tidak menimbulkan konflik gabungan dengan definisi yang ada di Gabungan. API Jika pembaruan di sumber API 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 API skema Gabungan ditolak karena konflik yang tidak didukung selama operasi penggabungan. Pesan kesalahan tersedia di konsol untuk setiap API asosiasi sumber yang memiliki statusMERGE_FAILED
. Anda juga dapat memeriksa pesan kesalahan dengan memanggil GetSourceApiAssociation
operasi untuk API asosiasi sumber tertentu menggunakan AWS SDK atau menggunakan AWS CLI sejenisnya:
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 sumber API adalah gabungan manual. Untuk menggabungkan perubahan apa pun yang terjadi di sumber APIs sejak Gabungan terakhir API diperbarui, API pemilik sumber dapat memanggil penggabungan manual dari AWS AppSync konsol atau melalui StartSchemaMerge
operasi yang tersedia di dan. AWS SDK AWS CLI
Dukungan tambahan untuk Gabungan APIs
Mengkonfigurasi langganan
Tidak seperti pendekatan berbasis router untuk komposisi skema GraphQL, Merged AWS AppSync menyediakan dukungan bawaan untuk langganan GraphQL. APIs Semua operasi langganan yang ditentukan dalam sumber terkait Anda APIs akan secara otomatis bergabung dan berfungsi di Gabungan Anda API tanpa modifikasi. Untuk mempelajari selengkapnya tentang cara AWS AppSync mendukung langganan melalui WebSockets koneksi tanpa server, lihat Data waktu nyata.
Mengkonfigurasi observabilitas
AWS AppSync Gabungan APIs menyediakan pencatatan, pemantauan, dan metrik bawaan melalui Amazon. CloudWatch AWS AppSync juga menyediakan dukungan bawaan untuk melacak via AWS X-Ray.
Mengkonfigurasi domain kustom
Mengkonfigurasi caching
AWS AppSync Digabungkan APIs memberikan dukungan bawaan untuk caching respons tingkat permintaan dan/atau tingkat resolver secara opsional serta kompresi respons. Untuk mempelajari lebih lanjut, lihat Caching dan kompresi.
Mengkonfigurasi pribadi APIs
Mengkonfigurasi aturan firewall
AWS AppSync Gabungan APIs menyediakan dukungan bawaan untuk AWS WAF, yang memungkinkan Anda untuk melindungi Anda APIs dengan mendefinisikan aturan firewall aplikasi web.
Mengkonfigurasi log audit
AWS AppSync Gabungan APIs menyediakan dukungan bawaan untuk AWS CloudTrail, yang memungkinkan Anda mengonfigurasi dan mengelola log audit.
Batasan gabungan API
Saat mengembangkan APIs Gabungan, perhatikan aturan berikut:
-
Gabungan tidak API dapat menjadi sumber API untuk API Gabungan lainnya.
-
Sumber API tidak dapat dikaitkan dengan lebih dari satu Gabungan. API
-
Batas ukuran default untuk dokumen API skema Gabungan adalah 10 MB.
-
Jumlah default sumber APIs yang dapat dikaitkan dengan Gabungan API adalah 10. Namun, Anda dapat meminta peningkatan batas jika Anda membutuhkan lebih dari 10 sumber APIs di API Gabungan Anda.
Membuat Gabungan APIs
Untuk membuat Gabungan API di konsol
-
Masuk ke AWS Management Console dan buka AWS AppSync konsol
. -
Di Dasbor, pilih Buat API.
-
-
Pilih Digabungkan API, lalu pilih Berikutnya.
-
Di halaman Tentukan API detail, masukkan informasi berikut:
-
Di bawah APIDetail, masukkan informasi berikut:
-
Tentukan APInama gabungan API Anda. Bidang ini adalah cara untuk memberi label GraphQL Anda agar mudah membedakannya dari API GraphQL lainnya. APIs
-
Tentukan detail Kontak. Bidang ini opsional dan melampirkan nama atau grup ke API GraphQL. Ini tidak ditautkan ke atau dihasilkan oleh sumber daya lain dan berfungsi seperti bidang API nama.
-
-
Di bawah peran Layanan, Anda harus melampirkan peran IAM eksekusi ke gabungan Anda API sehingga AWS AppSync dapat mengimpor dan menggunakan sumber daya Anda dengan aman saat runtime. Anda dapat memilih untuk membuat dan menggunakan peran layanan baru, yang akan memungkinkan Anda untuk menentukan kebijakan dan sumber daya yang AWS AppSync akan digunakan. Anda juga dapat mengimpor IAM peran yang ada dengan memilih Gunakan peran layanan yang ada, lalu memilih peran dari daftar drop-down.
-
Di bawah APIKonfigurasi pribadi, Anda dapat memilih untuk mengaktifkan API fitur pribadi. Perhatikan bahwa pilihan ini tidak dapat diubah setelah membuat gabunganAPI. Untuk informasi selengkapnya tentang pribadiAPIs, lihat Menggunakan AWS AppSync Pribadi APIs.
Pilih Berikutnya setelah Anda selesai.
-
-
Selanjutnya, Anda harus menambahkan APIs GraphQL yang akan digunakan sebagai fondasi untuk gabungan Anda. API Di APIs halaman Pilih sumber, masukkan informasi berikut:
-
Di tabel APIsfrom your AWS account, pilih Add Source APIs. Dalam daftar APIs GraphQL, setiap entri akan berisi data berikut:
-
Nama: Bidang nama API GraphQLAPI.
-
APIID: Nilai ID unik API GraphQL.
-
Mode autentikasi primer: Mode otorisasi default untuk GraphQL. API Untuk informasi selengkapnya tentang mode otorisasi AWS AppSync, lihat Otorisasi dan otentikasi.
-
Mode autentikasi tambahan: Mode otorisasi sekunder yang dikonfigurasi di GraphQL. API
-
Pilih APIs yang akan Anda gunakan dalam gabungan API dengan memilih kotak centang di sebelah bidang API Nama. Setelah itu, pilih Add Source APIs. APIsGraphQL yang dipilih akan muncul di tabel from AWS your APIs accounts.
-
-
Di tabel APIsfrom other AWS accounts, pilih Add Source APIs. APIsGraphQL dalam daftar ini berasal dari akun lain yang membagikan sumber daya mereka ke akun Anda AWS Resource Access Manager melalui ().AWS RAM Proses untuk memilih APIs GraphQL dalam tabel ini sama dengan proses di bagian sebelumnya. Untuk informasi selengkapnya tentang berbagi sumber daya AWS RAM, lihat Apa itu AWS Resource Access Manager? .
Pilih Berikutnya setelah Anda selesai.
-
Tambahkan mode autentikasi utama Anda. Lihat Otorisasi dan otentikasi untuk informasi selengkapnya. Pilih Berikutnya.
-
Tinjau input Anda, lalu pilih Buat API.
-