Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Menggabungkan APIs AWS AppSync Karena penggunaan GraphQL meluas dalam suatu organisasi, trade-off antara ease-of-use kecepatan pengembangan API dan 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 berbeda yang digabungkan menjadi satu titik akhir API GraphQL mungkin menginginkan kemampuan untuk membuat, mengelola, dan menerapkan pembaruan API secara independen satu sama lain. Ini meningkatkan kecepatan perkembangan 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 API gabungan. Ini memberi organisasi kemampuan untuk mempertahankan API lintas domain yang mudah digunakan, dan cara bagi tim yang berbeda yang berkontribusi pada API tersebut kemampuan untuk secara cepat dan mandiri membuat pembaruan API. Diagram berikut menunjukkan alur kerja API gabungan: ![\[Diagram yang menunjukkan alur kerja API gabungan dengan beberapa sumber digabungkan APIs menjadi satu titik akhir API gabungan\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/images/merged-api-workflow.png) Menggunakan Merged APIs, organisasi dapat mengimpor sumber daya dari beberapa sumber independen AWS AppSync APIs ke dalam satu titik akhir API AWS AppSync Gabungan. Untuk melakukan ini, AWS AppSync Anda dapat membuat daftar sumber AWS AppSync APIs, lalu menggabungkan semua metadata yang terkait dengan sumber APIs termasuk skema, tipe, sumber data, resolver, dan fungsi, ke dalam API gabungan baru. AWS AppSync Selama penggabungan, ada kemungkinan konflik penggabungan akan terjadi karena ketidakkonsistenan dalam konten data API 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 skema API sumber. API Gabungan yang dihasilkan hanya mengimpor semua jenis, resolver, sumber data, dan fungsi dari sumber aslinya. AWS AppSync APIs Untuk kasus penggunaan yang kompleks di mana konflik muncul, users/teams 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 API Gabungan terkait. ## 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 API Gabungan yang terpisah. 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, membangun rencana permintaan, dan kemudian mendistribusikan elemen permintaan di seluruh sub-grafik/server yang mendasarinya. Tabel berikut membandingkan pendekatan build-time AWS AppSync Merged API dengan pendekatan run-time berbasis router untuk komposisi skema GraphQL: | | | | | --- |--- |--- | | Fitur | AppSync API yang digabung | 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\$1 | Bervariasi | | Kompleksitas jaringan | API tunggal yang digabungkan berarti tidak ada lompatan 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. Server API Gabungan tunggal 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 | \$1 AWS AppSync Gabungan hanya APIs dapat dikaitkan dengan AWS AppSync sumber APIs. Jika Anda memerlukan dukungan untuk komposisi skema di seluruh AWS AppSync dan AWS AppSync non-sub-grafik, Anda dapat menghubungkan satu atau lebih GraphQL Merged ke dalam solusi berbasis AWS AppSync router and/or . 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](https://aws.amazon.com/blogs/mobile/federation-appsync-subgraph/) **Topics** + [Gabungan APIs dan Federasi](#merged-api-federation) + [Resolusi konflik API yang digabungkan](#merged-api-conflict-resolution) + [Mengkonfigurasi skema](#configuring-schemas-merged-api) + [Mengkonfigurasi mode otorisasi](#configuring-authorization-merged-api) + [Mengkonfigurasi peran eksekusi](#execution-roles-merged-api) + [Mengkonfigurasi Cross-Account Merged menggunakan APIs AWS RAM](#cross-account-merged-api) + [Penggabungan](#merges) + [Dukungan tambahan untuk Gabungan APIs](#merge-api-additional-support) + [Batasan API yang digabungkan](#merged-api-limits) + [Pertimbangan API yang digabungkan](#merged-api-considerations) + [Membuat Gabungan APIs](#creating-merged-api) ## Resolusi konflik API yang digabungkan Jika terjadi konflik penggabungan, AWS AppSync berikan beberapa alat dan contoh kepada pengguna 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 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 Konflik types/fields yang tidak dianotasi dengan arahan ini di sumber lain diabaikan saat APIs digabungkan. + *@hidden*: Arahan ini merangkum pasti types/fields untuk menghapusnya dari proses penggabungan. Tim mungkin ingin menghapus atau menyembunyikan jenis atau operasi tertentu di API sumber sehingga hanya klien internal yang dapat mengakses data tertentu yang diketik. Dengan direktif ini dilampirkan, tipe atau bidang tidak digabungkan ke dalam API Gabungan. + *@renamed*: Arahan ini mengubah nama types/fields 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 API Gabungan 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 sumber APIs. 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 referensi`User`, atau informasi poster (email dan alamat), dan`Message`, 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 lain`Message`. `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 daripada `User` 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, tetapi `Post` tipe dari Source2.graphQL tidak.* Biasanya, akan ada konflik pada tipe ini, tetapi karena `Post` 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, satu `GetMessage` kueri diganti namanya `GetChatMessage` 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 default 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 satu`id`, satu`title`, dan satu`reviews`. + `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 titik akhir Merged API, AWS AppSync layanan pertama-tama menjalankan unit resolver for `Query.getPost` from`Source1`, 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 di`id`. `$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 disebut`PostInfo`, yang berisi bidang konten dan penulis yang akan diselesaikan oleh *Source2.graphQL*. *Source1.graphQL* akan mengimplementasikan resolver yang dilampirkan`Query.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 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. ## Mengkonfigurasi skema Dua pihak bertanggung jawab untuk mengonfigurasi skema untuk membuat API Gabungan: + **Pemilik API yang digabungkan - Pemilik API** yang digabungkan harus mengonfigurasi logika otorisasi Gabungan API dan pengaturan lanjutan seperti pencatatan, penelusuran, caching, dan dukungan WAF. + **Pemilik API sumber terkait - Pemilik** API terkait harus mengonfigurasi skema, resolver, dan sumber data yang membentuk API Gabungan. **Karena skema Gabungan API Anda dibuat dari skema sumber terkait Anda APIs, 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 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 AWS AppSync, lihat [Otorisasi dan](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html) otentikasi. Mode otorisasi berikut tersedia untuk digunakan dengan APIs Gabungan: + **Kunci API**: Strategi otorisasi paling sederhana. Semua permintaan harus menyertakan kunci API di bawah header `x-api-key` permintaan. Kunci API yang kedaluwarsa disimpan selama 60 hari setelah tanggal kedaluwarsa. + **AWS Identity and Access Management (IAM)****: Strategi otorisasi AWS IAM 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 API Anda menggunakan logika kustom. AWS AppSync + **OpenID Connect: Jenis** otorisasi ini memberlakukan token OpenID connect (OIDC) yang disediakan oleh layanan yang sesuai dengan OIDC. Aplikasi Anda dapat memanfaatkan pengguna dan hak istimewa yang ditentukan oleh penyedia OIDC Anda untuk mengontrol akses. Mode otorisasi API Gabungan dikonfigurasi oleh pemilik API Gabungan. Pada saat operasi gabungan, 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 sumber APIs, proses penggabungan dapat secara otomatis menggabungkan arahan ini ke titik akhir terpadu. Jika mode otorisasi utama dari API sumber tidak cocok dengan mode otorisasi utama API Gabungan, mode ini akan secara otomatis menambahkan arahan autentikasi ini untuk memastikan bahwa mode otorisasi untuk tipe di API sumber konsisten. ## Mengkonfigurasi peran eksekusi Saat membuat API Gabungan, Anda perlu menentukan peran layanan. Peran AWS layanan adalah peran AWS Identity and Access Management (IAM) and Access Management (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 sumber Anda. APIs Peran layanan yang diperlukan untuk ini adalah`mergedApiExecutionRole`, dan harus memiliki akses eksplisit untuk menjalankan permintaan pada sumber yang APIs 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 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 API Gabungan, sebaiknya terapkan logika kustom dalam Lambda Anda atau menyembunyikan bidang API sumber dari API Gabungan menggunakan direktif @hidden.* Jika Anda ingin mengizinkan peran menjalankan 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 resolver turunan yang mengotorisasi 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/", "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] }] } ``` ------ Anda juga dapat menggunakan wizard pembuatan API AWS AppSync konsol untuk menghasilkan peran layanan agar API Gabungan dapat mengakses sumber daya yang dikonfigurasi di sumber APIs yang berada di akun yang sama dengan API gabungan Anda. Jika sumber Anda tidak APIs berada di akun yang sama dengan API gabungan Anda, Anda harus terlebih dahulu membagikan sumber daya menggunakan AWS Resource Access Manager (AWS RAM). ## Mengkonfigurasi Cross-Account Merged menggunakan APIs AWS RAM Saat membuat API Gabungan, 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 (OUs), dan dengan peran dan pengguna IAM. AWS AppSync terintegrasi dengan AWS RAM untuk mendukung konfigurasi dan mengakses sumber APIs di beberapa akun dari satu API Gabungan. 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 di RAM: 1. `AWSRAMPermissionAppSyncSourceApiOperationAccess`: Set izin default yang ditambahkan saat berbagi AWS AppSync API AWS RAM jika tidak ada izin lain yang ditentukan. Set izin ini digunakan untuk berbagi AWS AppSync API sumber dengan pemilik API Gabungan. Set izin ini mencakup izin untuk `appsync:AssociateMergedGraphqlApi` pada API sumber serta `appsync:SourceGraphQL` izin yang diperlukan untuk mengakses sumber daya API sumber saat runtime. 1. `AWSRAMPermissionAppSyncMergedApiOperationAccess`: Set izin ini harus dikonfigurasi saat berbagi API Gabungan dengan pemilik API sumber. Kumpulan izin ini akan memberi API sumber kemampuan untuk mengonfigurasi API Gabungan termasuk kemampuan untuk mengaitkan sumber apa pun yang APIs dimiliki oleh prinsipal target ke API Gabungan dan untuk membaca dan memperbarui asosiasi API sumber dari API Gabungan. 1. `AWSRAMPermissionAppSyncAllowSourceGraphQLAccess`: Set izin ini memungkinkan `appsync:SourceGraphQL` izin untuk digunakan dengan AWS AppSync API. Ini dimaksudkan untuk digunakan untuk berbagi API sumber dengan pemilik API Gabungan. Berbeda dengan izin default yang ditetapkan untuk akses operasi API sumber, set izin ini hanya menyertakan izin `appsync:SourceGraphQL` runtime. Jika pengguna memilih untuk membagikan akses operasi Gabungan API ke pemilik API sumber, mereka juga perlu membagikan izin ini dari API sumber kepada pemilik API Gabungan agar memiliki akses runtime melalui titik akhir API Gabungan. 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: 1. `appsync:AssociateSourceGraphqlApi` 1. `appsync:AssociateMergedGraphqlApi` 1. `appsync:GetSourceApiAssociation` 1. `appsync:UpdateSourceApiAssociation` 1. `appsync:StartSchemaMerge` 1. `appsync:ListTypesByAssociation` 1. `appsync:SourceGraphQL` 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 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 API apa pun 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 API AWS AppSync Gabungan Anda dapat dikonfigurasi untuk menggabungkan secara otomatis (penggabungan otomatis) ke dalam API Gabungan setelah perubahan apa pun 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 API Gabungan selama tidak menimbulkan konflik gabungan 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 status`MERGE_FAILED`. Anda juga dapat memeriksa pesan kesalahan dengan memanggil `GetSourceApiAssociation` operasi untuk asosiasi API sumber tertentu menggunakan AWS SDK atau menggunakan AWS CLI seperti: ``` aws appsync get-source-api-association --merged-api-identifier --association-id ``` Ini akan menghasilkan hasil dalam format berikut: ``` { "sourceApiAssociation": { "associationId": "", "associationArn": "", "sourceApiId": "", "sourceApiArn": "", "mergedApiArn": "", "mergedApiId": "", "sourceApiAssociationConfig": { "mergeType": "MANUAL_MERGE" }, "sourceApiAssociationStatus": "MERGE_FAILED", "sourceApiAssociationStatusDetail": "Unable to resolve conflict on object with name title: Merging is not supported for fields with different types." } } ``` ### Penggabungan manual Pengaturan default untuk API sumber adalah penggabungan manual. Untuk menggabungkan perubahan apa pun yang terjadi di sumber APIs sejak API Gabungan terakhir diperbarui, pemilik API sumber dapat memanggil penggabungan manual dari AWS AppSync konsol atau melalui `StartSchemaMerge` operasi yang tersedia di SDK AWS dan CLI. AWS ## 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 API Gabungan Anda tanpa modifikasi. [Untuk mempelajari selengkapnya tentang cara AWS AppSync mendukung langganan melalui WebSockets koneksi tanpa server, lihat Data waktu nyata.](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html) ### Mengkonfigurasi observabilitas AWS AppSync [Gabungan APIs menyediakan pencatatan, pemantauan, dan metrik bawaan melalui Amazon. CloudWatch](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html) AWS AppSync juga menyediakan dukungan bawaan untuk melacak via [AWS X-Ray](https://docs.aws.amazon.com/appsync/latest/devguide/x-ray-tracing.html). ### Mengkonfigurasi domain kustom AWS AppSync [Gabungan APIs menyediakan dukungan bawaan untuk menggunakan domain kustom dengan GraphQL dan titik akhir Real-time API Gabungan Anda.](https://docs.aws.amazon.com/appsync/latest/devguide/custom-domain-name.html) ### 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](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html). ### Mengkonfigurasi pribadi APIs AWS AppSync [Gabungan APIs menyediakan dukungan bawaan untuk Private APIs yang membatasi akses ke GraphQL API Gabungan Anda dan titik akhir Real-time untuk lalu lintas yang berasal dari titik akhir VPC yang dapat Anda konfigurasi.](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html) ### 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](https://docs.aws.amazon.com/appsync/latest/devguide/WAF-Integration.html). ### Mengkonfigurasi log audit AWS AppSync Gabungan APIs menyediakan dukungan bawaan untuk AWS CloudTrail, yang memungkinkan Anda [mengonfigurasi dan mengelola log audit](https://docs.aws.amazon.com/appsync/latest/devguide/cloudtrail-logging.html). ## Batasan API yang digabungkan Saat mengembangkan APIs Gabungan, perhatikan aturan berikut: 1. API Gabungan tidak dapat menjadi API sumber untuk API Gabungan lainnya. 1. API sumber tidak dapat dikaitkan dengan lebih dari satu API Gabungan. 1. Batas ukuran default untuk dokumen skema API Gabungan adalah 10 MB. 1. Jumlah default sumber APIs yang dapat dikaitkan dengan API Gabungan adalah 10. Namun, Anda dapat meminta peningkatan batas jika Anda membutuhkan lebih dari 10 sumber APIs di API Gabungan. ## Pertimbangan API yang digabungkan Saat merancang dan mengimplementasikan Merged APIs, pertimbangkan hal berikut: Menggabungkan beberapa sumber APIs menjadi satu titik akhir dapat meningkatkan ukuran dan kompleksitas skema dan kueri GraphQL Anda. Saat skema gabungan Anda bertambah, kueri mungkin perlu melintasi beberapa resolver untuk memenuhi satu permintaan, yang dapat menambahkan latensi ke keseluruhan waktu permintaan Anda. Misalnya, kueri yang mengakses bidang dari beberapa sumber APIs mungkin AWS AppSync perlu mengeksekusi resolver dari setiap API sumber secara berurutan, dengan setiap resolver menambah total waktu respons. Kami sangat menyarankan agar Anda menguji Gabungan Anda secara APIs menyeluruh selama pengembangan dan dalam kondisi beban yang realistis untuk memastikan mereka memenuhi persyaratan bisnis Anda. Berikan perhatian khusus pada: + Kedalaman dan kompleksitas skema gabungan Anda, terutama kueri yang mengakses bidang di beberapa sumber. APIs + Jumlah resolver yang harus mengeksekusi untuk memenuhi pola query umum. + Karakteristik kinerja sumber data dan resolver Anda di bawah beban yang diharapkan. + Dampak latensi jaringan saat mengakses sumber daya di berbagai sumber. APIs Pertimbangkan untuk menerapkan pengoptimalan kinerja seperti caching, pengelompokan permintaan sumber data, dan merancang skema API sumber Anda untuk meminimalkan jumlah eksekusi resolver yang diperlukan untuk operasi umum. ## Membuat Gabungan APIs **Untuk membuat API Gabungan di konsol** 1. Masuk ke Konsol Manajemen AWS dan buka [AWS AppSync konsol](https://console.aws.amazon.com/appsync/). 1. Di **Dasbor**, pilih **Buat API**. 1. Pilih **API Gabungan**, lalu pilih **Berikutnya**. 1. Di halaman **Tentukan detail API**, masukkan informasi berikut: 1. Di bawah **Detail API**, masukkan informasi berikut: 1. Tentukan **nama API** gabungan Anda. Bidang ini adalah cara untuk memberi label GraphQL API Anda untuk membedakannya dengan mudah dari GraphQL lainnya. APIs 1. Tentukan **detail Kontak**. Bidang ini bersifat opsional dan melampirkan nama atau grup ke GraphQL API. Ini tidak ditautkan ke atau dihasilkan oleh sumber daya lain dan berfungsi seperti bidang nama API. 1. Di bawah **peran Layanan**, Anda harus melampirkan peran eksekusi IAM ke API gabungan Anda 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 peran IAM yang ada dengan memilih **Gunakan peran layanan yang ada**, lalu memilih peran dari daftar drop-down. 1. Di bawah **konfigurasi API Pribadi**, Anda dapat memilih untuk mengaktifkan fitur API pribadi. Perhatikan bahwa pilihan ini tidak dapat diubah setelah membuat API gabungan. Untuk informasi selengkapnya tentang pribadi APIs, lihat [Menggunakan AWS AppSync Pribadi APIs](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html). Pilih **Berikutnya** setelah Anda selesai. 1. Selanjutnya, Anda harus menambahkan APIs GraphQL yang akan digunakan sebagai dasar untuk API gabungan Anda. Di APIs halaman **Pilih sumber**, masukkan informasi berikut: 1. Di tabel **APIs from your AWS account**, pilih **Add Source APIs**. Dalam daftar APIs GraphQL, setiap entri akan berisi data berikut: 1. **Nama**: Bidang nama API GraphQL API**.** 1. **API ID: Nilai ID** unik GraphQL API. 1. **Mode autentikasi primer: Mode** otorisasi default untuk GraphQL API. Untuk informasi selengkapnya tentang mode otorisasi AWS AppSync, lihat [Otorisasi dan](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html) otentikasi. 1. **Mode autentikasi tambahan: Mode** otorisasi sekunder yang dikonfigurasi di GraphQL API. 1. Pilih APIs yang akan Anda gunakan di API gabungan dengan memilih kotak centang di sebelah bidang **Nama** API. Setelah itu, pilih **Add Source APIs**. APIs GraphQL yang dipilih akan muncul di tabel **from AWS your APIs accounts**. 1. Di tabel **APIs from other AWS accounts**, pilih **Add Source APIs**. APIs GraphQL 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?](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) . Pilih **Berikutnya** setelah Anda selesai. 1. Tambahkan mode autentikasi utama Anda. Lihat [Otorisasi dan otentikasi untuk informasi](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html) selengkapnya. Pilih **Berikutnya**. 1. Tinjau input Anda, lalu pilih **Buat API**.