Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Komponen dari GraphQL API
GraphQL API standar terdiri dari skema tunggal yang menangani bentuk data yang akan ditanyakan. Skema Anda ditautkan ke satu atau beberapa sumber data Anda seperti database atau fungsi Lambda. Di antara keduanya duduk satu atau lebih resolver yang menangani logika bisnis untuk permintaan Anda. Setiap komponen memainkan peran penting dalam implementasi GraphQL Anda. Bagian berikut akan memperkenalkan ketiga komponen ini dan peran yang mereka mainkan dalam layanan GraphQL.
![\[GraphQL API components: schema, resolvers, and data sources interconnected with AppSync.\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/images/appsync-architecture-graphql-api.png)
**Topics**
+ [GraphQL skema](schema-components.md)
+ [Sumber data](data-source-components.md)
+ [Penyelesai](resolver-components.md)
# GraphQL skema
Skema GraphQL adalah dasar dari GraphQL API. Ini berfungsi sebagai cetak biru yang mendefinisikan bentuk data Anda. Ini juga merupakan kontrak antara klien dan server Anda yang menentukan bagaimana data Anda akan diambil dimodifikasi and/or .
Skema GraphQL ditulis dalam Schema Definition Language (*SDL*). SDL terdiri dari jenis dan bidang dengan struktur yang mapan:
+ **Jenis**: Jenis adalah bagaimana GraphQL mendefinisikan bentuk dan perilaku data. GraphQL mendukung banyak jenis yang akan dijelaskan nanti di bagian ini. Setiap jenis yang didefinisikan dalam skema Anda akan berisi cakupannya sendiri. Di dalam ruang lingkup akan ada satu atau lebih bidang yang dapat berisi nilai atau logika yang akan digunakan dalam layanan GraphQL Anda. Jenis mengisi banyak peran yang berbeda, yang paling umum adalah objek atau skalar (tipe nilai primitif).
+ **Bidang**: Bidang ada dalam lingkup tipe dan menyimpan nilai yang diminta dari layanan GraphQL. Ini sangat mirip dengan variabel dalam bahasa pemrograman lain. Bentuk data yang Anda tentukan di bidang Anda akan menentukan bagaimana data terstruktur dalam suatu request/response operasi. Hal ini memungkinkan pengembang untuk memprediksi apa yang akan dikembalikan tanpa mengetahui bagaimana backend layanan diimplementasikan.
Untuk memvisualisasikan seperti apa skema, mari kita tinjau isi skema GraphQL sederhana. Dalam kode produksi, skema Anda biasanya akan berada dalam file bernama `schema.graphql` atau`schema.json`. Mari kita asumsikan bahwa kita mengintip ke dalam proyek yang mengimplementasikan layanan GraphQL. Proyek ini menyimpan data personel perusahaan, dan `schema.graphql` file tersebut digunakan untuk mengambil data personel dan menambahkan personel baru ke database. Kode mungkin terlihat seperti ini:
------
#### [ schema.graphql ]
```
type Person {
id: ID!
name: String
age: Int
}
type Query {
people: [Person]
}
type Mutation {
addPerson(id: ID!, name: String, age: Int): Person
}
```
------
Kita dapat melihat bahwa ada tiga jenis yang didefinisikan dalam skema:`Person`,`Query`, dan`Mutation`. Melihat`Person`, kita dapat menebak bahwa ini adalah cetak biru untuk contoh karyawan perusahaan, yang akan membuat tipe ini menjadi objek. Di dalam ruang lingkupnya, kita lihat`id`,`name`, dan`age`. Ini adalah bidang yang menentukan properti dari a`Person`. Ini berarti sumber data kami menyimpan masing-masing `Person` `name` sebagai tipe `String` skalar (primitif) dan `age` sebagai tipe `Int` skalar (primitif). `id`Bertindak sebagai pengenal khusus dan unik untuk masing-masing`Person`. Ini juga merupakan nilai yang diperlukan seperti yang dilambangkan dengan simbol. `!`
Dua tipe objek berikutnya berperilaku berbeda. GraphQL menyimpan beberapa kata kunci untuk jenis objek khusus yang menentukan bagaimana data akan diisi dalam skema. `Query`Tipe akan mengambil data dari sumbernya. Dalam contoh kita, query kita mungkin mengambil `Person` objek dari database. Ini mungkin mengingatkan Anda tentang `GET` operasi dalam RESTful terminologi. A `Mutation` akan memodifikasi data. Dalam contoh kita, mutasi kita dapat menambahkan lebih banyak `Person` objek ke database. Ini mungkin mengingatkan Anda tentang operasi yang mengubah negara seperti `PUT` atau. `POST` Perilaku semua jenis objek khusus akan dijelaskan nanti di bagian ini.
Mari kita asumsikan `Query` dalam contoh kita akan mengambil sesuatu dari database. Jika kita melihat bidang`Query`, kita melihat satu bidang yang disebut`people`. Nilai bidangnya adalah`[Person]`. Ini berarti kita ingin mengambil beberapa contoh dari `Person` dalam database. Namun, penambahan tanda kurung berarti bahwa kita ingin mengembalikan daftar semua `Person` instance dan bukan hanya yang spesifik.
`Mutation`Tipe ini bertanggung jawab untuk melakukan operasi perubahan status seperti modifikasi data. Mutasi bertanggung jawab untuk melakukan beberapa operasi perubahan keadaan pada sumber data. Dalam contoh kita, mutasi kita berisi operasi yang disebut `addPerson` yang menambahkan `Person` objek baru ke database. Mutasi menggunakan a `Person` dan mengharapkan input untuk`id`,`name`, dan `age` bidang.
Pada titik ini, Anda mungkin bertanya-tanya bagaimana operasi seperti `addPerson` bekerja tanpa implementasi kode mengingat bahwa itu seharusnya melakukan beberapa perilaku dan terlihat sangat mirip fungsi dengan nama fungsi dan parameter. Saat ini, itu tidak akan berfungsi karena skema hanya berfungsi sebagai deklarasi. Untuk mengimplementasikan perilaku`addPerson`, kita harus menambahkan resolver ke dalamnya. Resolver adalah unit kode yang dieksekusi setiap kali bidang terkait (dalam hal ini, `addPerson` operasi) dipanggil. Jika Anda ingin menggunakan operasi, Anda harus menambahkan implementasi resolver di beberapa titik. Di satu sisi, Anda dapat menganggap operasi skema sebagai deklarasi fungsi dan resolver sebagai definisi. Resolver akan dijelaskan di bagian yang berbeda.
Contoh ini hanya menunjukkan cara paling sederhana skema dapat memanipulasi data. Anda membangun aplikasi yang kompleks, kuat, dan dapat diskalakan dengan memanfaatkan fitur GraphQL dan. AWS AppSync Di bagian selanjutnya, kita akan mendefinisikan semua jenis dan perilaku lapangan yang berbeda yang dapat Anda manfaatkan dalam skema Anda.
# Jenis GraphQL
GraphQL mendukung berbagai jenis. Seperti yang Anda lihat di bagian sebelumnya, tipe menentukan bentuk atau perilaku data Anda. Mereka adalah blok bangunan mendasar dari skema GraphQL.
Jenis dapat dikategorikan ke dalam input dan output. Input adalah tipe yang diizinkan untuk diteruskan sebagai argumen untuk tipe objek khusus (`Query`,, dll.)`Mutation`, sedangkan tipe output secara ketat digunakan untuk menyimpan dan mengembalikan data. Daftar jenis dan kategorisasi mereka tercantum di bawah ini:
+ **Objek**: Objek berisi bidang yang menggambarkan entitas. Misalnya, objek bisa berupa sesuatu seperti a `book` dengan bidang yang menggambarkan karakteristiknya seperti`authorName`,`publishingYear`, dll. Mereka benar-benar tipe output.
+ **Skalar**: Ini adalah tipe primitif seperti int, string, dll. Mereka biasanya ditugaskan ke bidang. Menggunakan `authorName` bidang sebagai contoh, dapat diberikan `String` skalar untuk menyimpan nama seperti “John Smith”. Skalar dapat berupa tipe input dan output.
+ **Input**: Input memungkinkan Anda untuk melewati sekelompok bidang sebagai argumen. Mereka terstruktur sangat mirip dengan objek, tetapi mereka dapat diteruskan sebagai argumen ke objek khusus. Input memungkinkan Anda untuk menentukan skalar, enum, dan input lain dalam cakupannya. Input hanya bisa berupa tipe input.
+ **Objek khusus**: Objek khusus melakukan operasi yang mengubah keadaan dan melakukan sebagian besar pengangkatan berat layanan. Ada tiga jenis objek khusus: kueri, mutasi, dan langganan. Kueri biasanya mengambil data; mutasi memanipulasi data; langganan membuka dan memelihara koneksi dua arah antara klien dan server untuk komunikasi konstan. Objek khusus bukanlah input atau output mengingat fungsinya.
+ **Enum**: Enum adalah daftar nilai hukum yang telah ditentukan sebelumnya. Jika Anda memanggil enum, nilainya hanya bisa menjadi apa yang didefinisikan dalam cakupannya. Misalnya, jika Anda memiliki enum yang disebut `trafficLights` menggambarkan daftar sinyal lalu lintas, itu bisa memiliki nilai seperti `redLight` dan `greenLight` tetapi tidak. `purpleLight` Lampu lalu lintas nyata hanya akan memiliki begitu banyak sinyal, sehingga Anda dapat menggunakan enum untuk mendefinisikannya dan memaksanya menjadi satu-satunya nilai hukum saat mereferensikan`trafficLight`. Enum dapat berupa tipe input dan output.
+ **Serikat/Antarmuka**: Serikat memungkinkan Anda mengembalikan satu atau lebih hal dalam permintaan tergantung pada data yang diminta oleh klien. Misalnya, jika Anda memiliki `Book` tipe dengan `title` bidang dan `Author` tipe dengan `name` bidang, Anda dapat membuat gabungan antara kedua jenis. *Jika klien Anda ingin menanyakan database untuk frasa “Julius Caesar”, serikat pekerja dapat mengembalikan *Julius Caesar* (drama oleh William Shakespeare) dari `Book` `title` dan *Julius Caesar* (penulis Commentarii de Bello Gallico) dari.* `Author` `name` Serikat pekerja hanya bisa menjadi tipe keluaran.
Antarmuka adalah kumpulan bidang yang harus diimplementasikan objek. Ini sedikit mirip dengan antarmuka dalam bahasa pemrograman seperti Java di mana Anda harus mengimplementasikan bidang yang ditentukan dalam antarmuka. Misalnya, katakanlah Anda membuat antarmuka yang disebut `Book` yang berisi `title` bidang. Katakanlah Anda kemudian membuat tipe yang disebut `Novel` yang diimplementasikan`Book`. Anda `Novel` harus memasukkan `title` bidang. Namun, Anda juga `Novel` bisa menyertakan bidang lain yang tidak ada di antarmuka seperti `pageCount` atau`ISBN`. Antarmuka hanya dapat berupa tipe output.
Bagian berikut akan menjelaskan bagaimana setiap jenis bekerja di GraphQL.
## Objek
Objek GraphQL adalah tipe utama yang akan Anda lihat dalam kode produksi. Dalam GraphQL, Anda dapat menganggap objek sebagai pengelompokan bidang yang berbeda (mirip dengan variabel dalam bahasa lain), dengan setiap bidang ditentukan oleh tipe (biasanya skalar atau objek lain) yang dapat menyimpan nilai. Objek mewakili unit data yang dapat retrieved/manipulated berasal dari implementasi layanan Anda.
Jenis objek dideklarasikan menggunakan `Type` kata kunci. Mari kita memodifikasi contoh skema kita sedikit:
```
type Person {
id: ID!
name: String
age: Int
occupation: Occupation
}
type Occupation {
title: String
}
```
Jenis objek di sini adalah `Person` dan`Occupation`. Setiap objek memiliki bidangnya sendiri dengan tipenya sendiri. Salah satu fitur GraphQL adalah kemampuan untuk mengatur bidang ke jenis lain. Anda dapat melihat `occupation` bidang `Person` berisi jenis `Occupation` objek. Kita dapat membuat asosiasi ini karena GraphQL hanya mendeskripsikan data dan bukan implementasi layanan.
## Skalar
Skalar pada dasarnya adalah tipe primitif yang menyimpan nilai. Dalam AWS AppSync, ada dua jenis skalar: skalar GraphQL default dan skalar. AWS AppSync Skalar biasanya digunakan untuk menyimpan nilai bidang dalam tipe objek. Jenis GraphQL default `Int` meliputi`Float`,,,`String`, `Boolean` dan. `ID` Mari kita gunakan contoh sebelumnya lagi:
```
type Person {
id: ID!
name: String
age: Int
occupation: Occupation
}
type Occupation {
title: String
}
```
Memilih `title` bidang `name` dan, keduanya memegang `String` skalar. `Name`dapat mengembalikan nilai string seperti "`John Smith`" dan judulnya dapat mengembalikan sesuatu seperti "`firefighter`”. Beberapa implementasi GraphQL juga mendukung skalar kustom menggunakan `Scalar` kata kunci dan menerapkan perilaku tipe. Namun, AWS AppSync saat ini **tidak mendukung** skalar khusus. Untuk daftar skalar, lihat [Jenis skalar](https://docs.aws.amazon.com//appsync/latest/devguide/scalars.html) di. AWS AppSync
## Masukan
Karena konsep tipe input dan output, ada batasan tertentu saat meneruskan argumen. Jenis yang biasanya perlu diteruskan, terutama objek, dibatasi. Anda dapat menggunakan tipe input untuk melewati aturan ini. Input adalah jenis yang berisi skalar, enum, dan jenis input lainnya.
Input didefinisikan menggunakan `input` kata kunci:
```
type Person {
id: ID!
name: String
age: Int
occupation: Occupation
}
type Occupation {
title: String
}
input personInput {
id: ID!
name: String
age: Int
occupation: occupationInput
}
input occupationInput {
title: String
}
```
Seperti yang Anda lihat, kita dapat memiliki input terpisah yang meniru tipe aslinya. Masukan ini akan sering digunakan dalam operasi lapangan Anda seperti ini:
```
type Person {
id: ID!
name: String
age: Int
occupation: Occupation
}
type Occupation {
title: String
}
input occupationInput {
title: String
}
type Mutation {
addPerson(id: ID!, name: String, age: Int, occupation: occupationInput): Person
}
```
Perhatikan bagaimana kita masih meneruskan `occupationInput` di tempat `Occupation` untuk membuat`Person`.
Ini hanyalah satu skenario untuk input. Mereka tidak perlu menyalin objek 1:1, dan dalam kode produksi, kemungkinan besar Anda tidak akan menggunakannya seperti ini. Ini adalah praktik yang baik untuk memanfaatkan skema GraphQL dengan mendefinisikan hanya apa yang perlu Anda masukan sebagai argumen.
Juga, input yang sama dapat digunakan dalam beberapa operasi, tetapi kami tidak menyarankan melakukan ini. Setiap operasi idealnya harus berisi salinan input uniknya sendiri jika persyaratan skema berubah.
## Benda khusus
GraphQL menyimpan beberapa kata kunci untuk objek khusus yang menentukan beberapa logika bisnis untuk bagaimana skema Anda akan data. retrieve/manipulate Paling-paling, bisa ada salah satu dari masing-masing kata kunci ini dalam skema. Mereka bertindak sebagai titik masuk untuk semua data yang diminta yang dijalankan klien Anda terhadap layanan GraphQL Anda.
Objek khusus juga didefinisikan menggunakan `type` kata kunci. Meskipun mereka digunakan secara berbeda dari tipe objek biasa, implementasinya sangat mirip.
------
#### [ Queries ]
Kueri sangat mirip dengan `GET` operasi karena mereka melakukan pengambilan hanya-baca untuk mendapatkan data dari sumber Anda. Dalam GraphQL, `Query` mendefinisikan semua titik masuk untuk klien yang membuat permintaan terhadap server Anda. Akan selalu ada `Query` dalam implementasi GraphQL Anda.
Berikut adalah jenis objek `Query` dan modifikasi yang kami gunakan dalam contoh skema kami sebelumnya:
```
type Person {
id: ID!
name: String
age: Int
occupation: Occupation
}
type Occupation {
title: String
}
type Query {
people: [Person]
}
```
Kami `Query` berisi bidang `people` yang disebut yang mengembalikan daftar `Person` contoh dari sumber data. Katakanlah kita perlu mengubah perilaku aplikasi kita, dan sekarang kita perlu mengembalikan daftar hanya `Occupation` instance untuk beberapa tujuan terpisah. Kami cukup menambahkannya ke kueri:
```
type Query {
people: [Person]
occupations: [Occupation]
}
```
Di GraphQL, kami dapat memperlakukan kueri kami sebagai sumber permintaan tunggal. Seperti yang Anda lihat, ini berpotensi jauh lebih sederhana daripada RESTful implementasi yang mungkin menggunakan titik akhir yang berbeda untuk mencapai hal yang sama (`.../api/1/people`dan`.../api/1/occupations`).
Dengan asumsi kita memiliki implementasi resolver untuk query ini, kita sekarang dapat melakukan query yang sebenarnya. Sementara `Query` jenisnya ada, kita harus secara eksplisit memanggilnya agar dapat dijalankan dalam kode aplikasi. Ini dapat dilakukan dengan menggunakan `query` kata kunci:
```
query getItems {
people {
name
}
occupations {
title
}
}
```
Seperti yang Anda lihat, kueri ini dipanggil `getItems` dan dikembalikan `people` (daftar `Person` objek) dan `occupations` (daftar `Occupation` objek). Di`people`, kami hanya mengembalikan `name` bidang masing-masing`Person`, sementara kami mengembalikan `title` bidang masing-masing`Occupation`. Responsnya mungkin terlihat seperti ini:
```
{
"data": {
"people": [
{
"name": "John Smith"
},
{
"name": "Andrew Miller"
},
.
.
.
],
"occupations": [
{
"title": "Firefighter"
},
{
"title": "Bookkeeper"
},
.
.
.
]
}
}
```
Contoh respon menunjukkan bagaimana data mengikuti bentuk query. Setiap entri yang diambil tercantum dalam lingkup bidang. `people`dan mengembalikan `occupations` hal-hal sebagai daftar terpisah. Meskipun berguna, mungkin lebih mudah untuk memodifikasi kueri untuk mengembalikan daftar nama dan pekerjaan orang:
```
query getItems {
people {
name
occupation {
title
}
}
```
Ini adalah modifikasi hukum karena `Person` tipe kami berisi `occupation` bidang tipe`Occupation`. Ketika terdaftar dalam lingkup`people`, kami mengembalikan masing-masing `Person` `name` bersama dengan yang terkait dengannya `Occupation``title`. Responsnya mungkin terlihat seperti ini:
```
}
"data": {
"people": [
{
"name": "John Smith",
"occupation": {
"title": "Firefighter"
}
},
{
"name": "Andrew Miller",
"occupation": {
"title": "Bookkeeper"
}
},
.
.
.
]
}
}
```
------
#### [ Mutations ]
Mutasi mirip dengan operasi yang mengubah keadaan seperti atau. `PUT` `POST` Mereka melakukan operasi tulis untuk memodifikasi data di sumber, lalu mengambil responsnya. Mereka menentukan titik masuk Anda untuk permintaan modifikasi data. Tidak seperti kueri, mutasi mungkin atau mungkin tidak termasuk dalam skema tergantung pada kebutuhan proyek. Berikut mutasi dari contoh skema:
```
type Mutation {
addPerson(id: ID!, name: String, age: Int): Person
}
```
`addPerson`Bidang mewakili satu titik masuk yang menambahkan a `Person` ke sumber data. `addPerson`adalah nama bidang;`id`,`name`, dan `age` merupakan parameter; dan `Person` merupakan tipe pengembalian. Melihat kembali `Person` jenisnya:
```
type Person {
id: ID!
name: String
age: Int
occupation: Occupation
}
```
Kami menambahkan `occupation` bidang. Namun, kami tidak dapat mengatur bidang ini secara `Occupation` langsung karena objek tidak dapat diteruskan sebagai argumen; mereka benar-benar tipe keluaran. Sebagai gantinya, kita harus meneruskan input dengan bidang yang sama sebagai argumen:
```
input occupationInput {
title: String
}
```
Kami juga dapat dengan mudah memperbarui kami `addPerson` untuk memasukkan ini sebagai parameter saat membuat `Person` instance baru:
```
type Mutation {
addPerson(id: ID!, name: String, age: Int, occupation: occupationInput): Person
}
```
Berikut skema yang diperbarui:
```
type Person {
id: ID!
name: String
age: Int
occupation: Occupation
}
type Occupation {
title: String
}
input occupationInput {
title: String
}
type Mutation {
addPerson(id: ID!, name: String, age: Int, occupation: occupationInput): Person
}
```
Perhatikan bahwa `occupation` akan lulus di `title` bidang dari `occupationInput` untuk menyelesaikan pembuatan `Person` bukan `Occupation` objek asli. Dengan asumsi kita memiliki implementasi resolver untuk`addPerson`, kita sekarang dapat melakukan mutasi yang sebenarnya. Sementara `Mutation` jenisnya ada, kita harus secara eksplisit memanggilnya agar dapat dijalankan dalam kode aplikasi. Ini dapat dilakukan dengan menggunakan `mutation` kata kunci:
```
mutation createPerson {
addPerson(id: ID!, name: String, age: Int, occupation: occupationInput) {
name
age
occupation {
title
}
}
}
```
Mutasi ini disebut`createPerson`, dan `addPerson` merupakan operasi. Untuk membuat yang baru`Person`, kita bisa memasukkan argumen untuk`id`,`name`,`age`, dan`occupation`. Dalam lingkup`addPerson`, kita juga dapat melihat bidang lain seperti`name`,`age`, dll. Ini adalah tanggapan Anda; ini adalah bidang yang akan dikembalikan setelah `addPerson` operasi selesai. Inilah bagian terakhir dari contoh:
```
mutation createPerson {
addPerson(id: "1", name: "Steve Powers", age: "50", occupation: "Miner") {
id
name
age
occupation {
title
}
}
}
```
Menggunakan mutasi ini, hasilnya mungkin terlihat seperti ini:
```
{
"data": {
"addPerson": {
"id": "1",
"name": "Steve Powers",
"age": "50",
"occupation": {
"title": "Miner"
}
}
}
}
```
Seperti yang Anda lihat, respons mengembalikan nilai yang kami minta dalam format yang sama yang ditentukan dalam mutasi kami. Merupakan praktik yang baik untuk mengembalikan semua nilai yang telah dimodifikasi untuk mengurangi kebingungan dan kebutuhan akan lebih banyak kueri di masa mendatang. Mutasi memungkinkan Anda untuk memasukkan beberapa operasi dalam cakupannya. Mereka akan dijalankan secara berurutan dalam urutan yang tercantum dalam mutasi. Misalnya, jika kita membuat operasi lain `addOccupation` yang disebut yang menambahkan judul pekerjaan ke sumber data, kita dapat memanggil ini dalam mutasi setelahnya`addPerson`. `addPerson`akan ditangani terlebih dahulu diikuti oleh`addOccupation`.
------
#### [ Subscriptions ]
Langganan digunakan [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications)untuk membuka koneksi dua arah yang langgeng antara server dan kliennya. Biasanya, klien akan berlangganan, atau mendengarkan, ke server. Setiap kali server membuat perubahan sisi server atau melakukan acara, klien berlangganan akan menerima pembaruan. Jenis protokol ini berguna ketika beberapa klien berlangganan dan perlu diberitahu tentang perubahan yang terjadi di server atau klien lain. Misalnya, langganan dapat digunakan untuk memperbarui umpan media sosial. Mungkin ada dua pengguna, Pengguna A dan Pengguna B, yang keduanya berlangganan pembaruan notifikasi otomatis setiap kali mereka menerima pesan langsung. Pengguna A pada Klien A dapat mengirim pesan langsung ke Pengguna B pada Klien B. Klien Pengguna A akan mengirim pesan langsung, yang akan diproses oleh server. Server kemudian akan mengirim pesan langsung ke akun Pengguna B saat mengirim pemberitahuan otomatis ke Klien B.
Berikut adalah contoh `Subscription` yang bisa kita tambahkan ke contoh skema:
```
type Subscription {
personAdded: Person
}
```
`personAdded`Bidang akan mengirim pesan ke klien berlangganan setiap kali baru `Person` ditambahkan ke sumber data. Dengan asumsi kami memiliki implementasi resolver untuk`personAdded`, kami sekarang dapat menggunakan langganan. Sementara `Subscription` jenisnya ada, kita harus secara eksplisit memanggilnya agar dapat dijalankan dalam kode aplikasi. Ini dapat dilakukan dengan menggunakan `subscription` kata kunci:
```
subscription personAddedOperation {
personAdded {
id
name
}
}
```
Langganan disebut`personAddedOperation`, dan operasinya`personAdded`. `personAdded`akan mengembalikan `id` dan `name` bidang `Person` instance baru. Melihat contoh mutasi, kami menambahkan `Person` menggunakan operasi ini:
```
addPerson(id: "1", name: "Steve Powers", age: "50", occupation: "Miner")
```
Jika klien kami berlangganan pembaruan yang baru ditambahkan`Person`, mereka mungkin melihat ini setelah `addPerson` dijalankan:
```
{
"data": {
"personAdded": {
"id": "1",
"name": "Steve Powers"
}
}
}
```
Di bawah ini adalah ringkasan dari apa yang ditawarkan langganan:
Langganan adalah saluran dua arah yang memungkinkan klien dan server menerima pembaruan yang cepat, tetapi stabil. Mereka biasanya menggunakan WebSocket protokol, yang menciptakan koneksi standar dan aman.
Langganan gesit karena mengurangi overhead pengaturan koneksi. Setelah berlangganan, klien dapat terus menjalankan langganan itu untuk jangka waktu yang lama. Mereka umumnya menggunakan sumber daya komputasi secara efisien dengan memungkinkan pengembang untuk menyesuaikan masa pakai langganan dan untuk mengkonfigurasi informasi apa yang akan diminta.
Secara umum, langganan memungkinkan klien untuk membuat beberapa langganan sekaligus. Sehubungan dengan itu AWS AppSync, langganan hanya digunakan untuk menerima pembaruan waktu nyata dari layanan. AWS AppSync Mereka tidak dapat digunakan untuk melakukan kueri atau mutasi.
Alternatif utama untuk langganan adalah polling, yang mengirimkan kueri pada interval yang ditetapkan untuk meminta data. Proses ini biasanya kurang efisien daripada langganan dan menempatkan banyak tekanan pada klien dan backend.
------
Satu hal yang tidak disebutkan dalam contoh skema kami adalah fakta bahwa tipe objek khusus Anda juga harus didefinisikan dalam `schema` root. Jadi saat Anda mengekspor skema AWS AppSync, mungkin terlihat seperti ini:
------
#### [ schema.graphql ]
```
schema {
query: Query
mutation: Mutation
subscription: Subscription
}
.
.
.
type Query {
# code goes here
}
type Mutation {
# code goes here
}
type Subscription {
# code goes here
}
```
------
## Pencacahan
Enumerasi, atau enum, adalah skalar khusus yang membatasi argumen hukum yang mungkin dimiliki tipe atau bidang. Ini berarti bahwa setiap kali enum didefinisikan dalam skema, jenis atau bidang terkait akan terbatas pada nilai dalam enum. Enum diserialkan sebagai skalar string. Perhatikan bahwa bahasa pemrograman yang berbeda dapat menangani enum GraphQL secara berbeda. Misalnya, tidak JavaScript memiliki dukungan enum asli, sehingga nilai enum dapat dipetakan ke nilai int sebagai gantinya.
Enum didefinisikan menggunakan `enum` kata kunci. Inilah contohnya:
```
enum trafficSignals {
solidRed
solidYellow
solidGreen
greenArrowLeft
...
}
```
Saat memanggil `trafficLights` enum, argumen hanya bisa`solidRed`,, `solidYellow``solidGreen`, dll. Adalah umum untuk menggunakan enum untuk menggambarkan hal-hal yang memiliki jumlah pilihan yang berbeda tetapi terbatas.
## Serikat Serikat/Antarmuka
Lihat [Antarmuka dan serikat pekerja di GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/interfaces-and-unions.html).
# Bidang GraphQL
Bidang ada dalam lingkup tipe dan menyimpan nilai yang diminta dari layanan GraphQL. Ini sangat mirip dengan variabel dalam bahasa pemrograman lain. Misalnya, berikut adalah tipe `Person` objek:
```
type Person {
name: String
age: Int
}
```
Bidang dalam hal ini adalah `name` `age` dan dan memegang `Int` nilai `String` dan, masing-masing. Bidang objek seperti yang ditunjukkan di atas dapat digunakan sebagai input di bidang (operasi) kueri dan mutasi Anda. Misalnya, lihat `Query` di bawah ini:
```
type Query {
people: [Person]
}
```
`people`Bidang meminta semua contoh `Person` dari sumber data. Ketika Anda menambahkan atau mengambil `Person` di server GraphQL Anda, Anda dapat mengharapkan data mengikuti format tipe dan bidang Anda, yaitu, struktur data Anda dalam skema menentukan bagaimana itu akan disusun dalam respons Anda:
```
}
"data": {
"people": [
{
"name": "John Smith",
"age": "50"
},
{
"name": "Andrew Miller",
"age": "60"
},
.
.
.
]
}
}
```
Bidang memainkan peran penting dalam penataan data. Ada beberapa properti tambahan yang dijelaskan di bawah ini yang dapat diterapkan ke bidang untuk penyesuaian lebih lanjut.
## Daftar
Daftar mengembalikan semua item dari jenis tertentu. Daftar dapat ditambahkan ke jenis bidang menggunakan tanda kurung`[]`:
```
type Person {
name: String
age: Int
}
type Query {
people: [Person]
}
```
Dalam`Query`, tanda kurung di sekitarnya `Person` menunjukkan bahwa Anda ingin mengembalikan semua contoh dari `Person` dari sumber data sebagai array. Sebagai tanggapan, `age` nilai `name` dan masing-masing `Person` akan dikembalikan sebagai daftar tunggal yang dibatasi:
```
}
"data": {
"people": [
{
"name": "John Smith", # Data of Person 1
"age": "50"
},
{
"name": "Andrew Miller", # Data of Person 2
"age": "60"
},
. # Data of Person N
.
.
]
}
}
```
Anda tidak terbatas pada jenis objek khusus. Anda juga dapat menggunakan daftar di bidang jenis objek biasa.
## Non-nol
Non-null menunjukkan bidang yang tidak bisa null dalam respons. Anda dapat mengatur bidang ke non-null dengan menggunakan simbol: `!`
```
type Person {
name: String!
age: Int
}
type Query {
people: [Person]
}
```
`name`Bidang tidak bisa secara eksplisit nol. Jika Anda menanyakan sumber data dan memberikan input nol untuk bidang ini, kesalahan akan muncul.
Anda dapat menggabungkan daftar dan non-null. Bandingkan pertanyaan ini:
```
type Query {
people: [Person!] # Use case 1
}
.
.
.
type Query {
people: [Person]! # Use case 2
}
.
.
.
type Query {
people: [Person!]! # Use case 3
}
```
Dalam kasus penggunaan 1, daftar tidak dapat berisi item nol. Dalam kasus penggunaan 2, daftar itu sendiri tidak dapat diatur ke null. Dalam kasus penggunaan 3, daftar dan item-itemnya tidak bisa null. Namun, bagaimanapun, Anda masih dapat mengembalikan daftar kosong.
Seperti yang Anda lihat, ada banyak komponen bergerak di GraphQL. Pada bagian ini, kami menunjukkan struktur skema sederhana dan berbagai jenis dan bidang yang didukung skema. Di bagian berikut, Anda akan menemukan komponen lain dari GraphQL API dan bagaimana mereka bekerja dengan skema.
# Sumber data
Pada bagian sebelumnya, kita belajar bahwa skema mendefinisikan bentuk data Anda. Namun, kami tidak pernah menjelaskan dari mana data itu berasal. Dalam proyek nyata, skema Anda seperti gateway yang menangani semua permintaan yang dibuat ke server. Ketika permintaan dibuat, skema bertindak sebagai titik akhir tunggal yang berinteraksi dengan klien. Skema akan mengakses, memproses, dan menyampaikan data dari sumber data kembali ke klien. Lihat infografis di bawah ini:
![\[GraphQL schema integrating multiple Layanan AWS for a single endpoint API architecture.\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/images/aws-flow-infographic.png)
AWS AppSync dan GraphQL mengimplementasikan solusi Backend For Frontend (BFF) dengan luar biasa. Mereka bekerja bersama-sama untuk mengurangi kompleksitas pada skala besar dengan mengabstraksi backend. Jika layanan Anda menggunakan sumber data dan/atau layanan mikro yang berbeda, pada dasarnya Anda dapat mengabstraksikan beberapa kompleksitas dengan mendefinisikan bentuk data dari setiap sumber (subgraf) dalam satu skema (supergraf). Ini berarti GraphQL API Anda tidak terbatas pada penggunaan satu sumber data. Anda dapat mengaitkan sejumlah sumber data dengan GraphQL API Anda dan menentukan dalam kode Anda bagaimana mereka akan berinteraksi dengan layanan.
Seperti yang Anda lihat di infografis, skema GraphQL berisi semua informasi yang dibutuhkan klien untuk meminta data. Ini berarti semuanya dapat diproses dalam satu permintaan daripada beberapa permintaan seperti halnya dengan REST. Permintaan ini melalui skema, yang merupakan satu-satunya titik akhir layanan. Ketika permintaan diproses, resolver (dijelaskan di bagian berikutnya) mengeksekusi kodenya untuk memproses data dari sumber data yang relevan. Ketika respons dikembalikan, subgraf yang terkait dengan sumber data akan diisi dengan data dalam skema.
AWS AppSync mendukung berbagai jenis sumber data. Pada tabel di bawah ini, kami akan menjelaskan setiap jenis, mencantumkan beberapa manfaat masing-masing, dan memberikan tautan yang berguna untuk konteks tambahan.
| Sumber data | Deskripsi | Manfaat | Informasi tambahan |
| --- | --- | --- | --- |
| Amazon DynamoDB | Amazon DynamoDB adalah layanan database NoSQL yang dikelola sepenuhnya yang memberikan kinerja yang cepat dan dapat diprediksi dengan skalabilitas yang mulus. DynamoDB memungkinkan Anda meringankan beban administratif pengoperasian dan penskalaan basis data terdistribusi sehingga Anda tidak perlu khawatir tentang penyediaan perangkat keras, penyiapan dan konfigurasi, replikasi, patching perangkat lunak, atau penskalaan klaster. DynamoDB juga menawarkan enkripsi saat istirahat, yang menghilangkan beban operasional dan kompleksitas yang terlibat dalam melindungi data sensitif. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) |
| AWS Lambda | “AWS Lambda adalah layanan komputasi yang memungkinkan Anda menjalankan kode tanpa menyediakan atau mengelola server.Lambda menjalankan kode Anda pada infrastruktur komputasi ketersediaan tinggi dan melakukan semua administrasi sumber daya komputasi, termasuk pemeliharaan server dan sistem operasi, penyediaan kapasitas dan penskalaan otomatis, dan logging. Dengan Lambda, yang perlu Anda lakukan hanyalah menyediakan kode Anda di salah satu runtime bahasa yang didukung Lambda. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) |
| OpenSearch | Amazon OpenSearch Service adalah layanan terkelola yang memudahkan penerapan, pengoperasian, dan skala OpenSearch cluster di AWS Cloud. Amazon OpenSearch Service mendukung OpenSearch dan warisan Elasticsearch OSS (hingga 7.10, versi open source terakhir dari perangkat lunak). Saat Anda membuat cluster, Anda memiliki opsi mesin pencari mana yang akan digunakan.**OpenSearch**adalah mesin pencari dan analitik sumber terbuka sepenuhnya untuk kasus penggunaan seperti analitik log, pemantauan aplikasi waktu nyata, dan analisis clickstream. Lihat informasi yang lebih lengkap dalam [dokumentasi OpenSearch](https://opensearch.org/docs/).** OpenSearch Layanan Amazon menyediakan** semua sumber daya untuk OpenSearch klaster Anda dan meluncurkannya. Ini juga secara otomatis mendeteksi dan mengganti node OpenSearch Layanan yang gagal, mengurangi overhead yang terkait dengan infrastruktur yang dikelola sendiri. Anda dapat menskalakan klaster Anda dengan satu panggilan API atau beberapa klik di konsol.” | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) |
| Titik akhir HTTP | Anda dapat menggunakan titik akhir HTTP sebagai sumber data. AWS AppSync dapat mengirim permintaan ke titik akhir dengan informasi yang relevan seperti params dan payload. Respons HTTP akan diekspos ke resolver, yang akan mengembalikan respons akhir setelah selesai operasinya. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) |
| Amazon EventBridge | “EventBridge adalah layanan tanpa server yang menggunakan peristiwa untuk menghubungkan komponen aplikasi bersama-sama, sehingga memudahkan Anda untuk membangun aplikasi berbasis peristiwa yang dapat diskalakan. Gunakan untuk merutekan acara dari sumber seperti aplikasi rumahan, AWS layanan, dan perangkat lunak pihak ketiga ke aplikasi konsumen di seluruh organisasi Anda. EventBridge menyediakan cara sederhana dan konsisten untuk menelan, memfilter, mengubah, dan menyampaikan acara sehingga Anda dapat membangun aplikasi baru dengan cepat. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) |
| Basis data relasional | Amazon Relational Database Service (Amazon RDS) adalah layanan web yang membuatnya lebih mudah untuk mengatur, mengoperasikan, dan menskalakan database relasional di Cloud. AWS Ini menyediakan efisiensi biaya, kapasitas resizable untuk database relasional standar industri dan mengelola tugas-tugas administrasi database umum. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) |
| Tidak ada sumber data | Jika Anda tidak berencana menggunakan layanan sumber data, Anda dapat mengaturnyanone. Sumber none data, meskipun masih secara eksplisit dikategorikan sebagai sumber data, bukanlah media penyimpanan. Meskipun demikian, ini masih berguna dalam kasus tertentu untuk manipulasi data dan pass-through. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/data-source-components.html) |
**Tip**
Untuk informasi selengkapnya tentang cara sumber data berinteraksi AWS AppSync, lihat [Melampirkan sumber data](https://docs.aws.amazon.com//appsync/latest/devguide/attaching-a-data-source.html).
# Penyelesai
Dari bagian sebelumnya, Anda belajar tentang komponen skema dan sumber data. Sekarang, kita perlu membahas bagaimana skema dan sumber data berinteraksi. Semuanya dimulai dengan resolver.
Resolver adalah unit kode yang menangani bagaimana data bidang itu akan diselesaikan ketika permintaan dibuat ke layanan. Resolver dilampirkan ke bidang tertentu dalam tipe Anda dalam skema Anda. Mereka paling sering digunakan untuk mengimplementasikan operasi perubahan status untuk kueri, mutasi, dan operasi bidang langganan Anda. Penyelesai akan memproses permintaan klien, lalu mengembalikan hasilnya, yang dapat berupa sekelompok tipe keluaran seperti objek atau skalar:
![\[GraphQL schema with resolvers connecting to various AWS data sources for a single endpoint.\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/images/aws-flow-infographic.png)
## Runtime penyelesai
Di AWS AppSync, Anda harus terlebih dahulu menentukan runtime untuk resolver Anda. Runtime resolver menunjukkan lingkungan di mana resolver dijalankan. Ini juga menentukan bahasa yang akan ditulis oleh resolver Anda. AWS AppSync saat ini mendukung APPSYNC\$1JS untuk JavaScript dan Velocity Template Language (VTL). Lihat [fitur JavaScript runtime untuk resolver dan fungsi](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference-js.html) untuk JavaScript atau referensi utilitas template [pemetaan Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference.html) untuk VTL.
## Struktur penyelesai
Dari segi kode, resolver dapat disusun dalam beberapa cara. Ada resolver **unit** dan **pipa**.
### Penyelesai unit
Unit resolver terdiri dari kode yang mendefinisikan permintaan tunggal dan penangan respons yang dijalankan terhadap sumber data. Handler permintaan mengambil objek konteks sebagai argumen dan mengembalikan payload permintaan yang digunakan untuk memanggil sumber data Anda. Response handler menerima payload kembali dari sumber data dengan hasil dari permintaan yang dieksekusi. Response handler mengubah payload menjadi respons GraphQL untuk menyelesaikan bidang GraphQL.
![\[GraphQL request flow showing request and response handlers interacting with a data source.\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/images/unit-resolver-js.png)
### Penyelesai pipa
Saat menerapkan resolver pipa, ada struktur umum yang mereka ikuti:
+ **Sebelum langkah**: Ketika permintaan dibuat oleh klien, resolver untuk bidang skema yang digunakan (biasanya kueri, mutasi, langganan Anda) diteruskan data permintaan. Penyelesai akan mulai memproses data permintaan dengan penangan langkah sebelum, yang memungkinkan beberapa operasi pra-pemrosesan dilakukan sebelum data bergerak melalui resolver.
+ **Fungsi**: Setelah langkah sebelum berjalan, permintaan diteruskan ke daftar fungsi. Fungsi pertama dalam daftar akan dijalankan terhadap sumber data. Fungsi adalah subset dari kode resolver Anda yang berisi permintaan dan penangan responsnya sendiri. Seorang penangan permintaan akan mengambil data permintaan dan melakukan operasi terhadap sumber data. Response handler akan memproses respon sumber data sebelum meneruskannya kembali ke daftar. Jika ada lebih dari satu fungsi, data permintaan akan dikirim ke fungsi berikutnya dalam daftar yang akan dieksekusi. Fungsi dalam daftar akan dijalankan secara serial dalam urutan yang ditentukan oleh pengembang. Setelah semua fungsi dieksekusi, hasil akhir diteruskan ke langkah setelahnya.
+ **Langkah setelah: Langkah** setelah adalah fungsi handler yang memungkinkan Anda melakukan beberapa operasi akhir pada respons fungsi akhir sebelum meneruskannya ke respons GraphQL.
![\[GraphQL request flow diagram showing interactions between request, data sources, and response components.\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/images/appsync-js-resolver-logic.png)
## Struktur penangan penyelesai
Handler biasanya fungsi yang disebut `Request` dan`Response`:
```
export function request(ctx) {
// Code goes here
}
export function response(ctx) {
// Code goes here
}
```
Dalam unit resolver, hanya akan ada satu set fungsi ini. Dalam resolver pipa, akan ada satu set ini untuk langkah sebelum dan sesudah dan satu set tambahan per fungsi. Untuk memvisualisasikan bagaimana ini bisa terlihat, mari kita tinjau `Query` jenis sederhana:
```
type Query {
helloWorld: String!
}
```
Ini adalah kueri sederhana dengan satu bidang `helloWorld` yang disebut tipe`String`. Mari kita asumsikan kita selalu ingin bidang ini mengembalikan string “Hello World”. Untuk menerapkan perilaku ini, kita perlu menambahkan resolver ke bidang ini. Dalam unit resolver, kita bisa menambahkan sesuatu seperti ini:
```
export function request(ctx) {
return {}
}
export function response(ctx) {
return "Hello World"
}
```
Itu `request` bisa dibiarkan kosong karena kami tidak meminta atau memproses data. Kami juga dapat mengasumsikan sumber data kami`None`, menunjukkan kode ini tidak perlu melakukan pemanggilan apa pun. Responsnya hanya mengembalikan “Hello World”. Untuk menguji resolver ini, kita perlu membuat permintaan menggunakan tipe query:
```
query helloWorldTest {
helloWorld
}
```
Ini adalah kueri `helloWorldTest` yang disebut yang mengembalikan `helloWorld` bidang. Saat dijalankan, penyelesai `helloWorld` bidang juga mengeksekusi dan mengembalikan respons:
```
{
"data": {
"helloWorld": "Hello World"
}
}
```
Mengembalikan konstanta seperti ini adalah hal paling sederhana yang dapat Anda lakukan. Pada kenyataannya, Anda akan mengembalikan input, daftar, dan banyak lagi. Berikut contoh yang lebih rumit:
```
type Book {
id: ID!
title: String
}
type Query {
getBooks: [Book]
}
```
Di sini kita mengembalikan daftar`Books`. Mari kita asumsikan kita menggunakan tabel DynamoDB untuk menyimpan data buku. Penangan kami mungkin terlihat seperti ini:
```
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
return { operation: 'Scan' };
}
/**
* return a list of scanned post items
*/
export function response(ctx) {
return ctx.result.items;
}
```
Permintaan kami menggunakan operasi pemindaian bawaan untuk mencari semua entri dalam tabel, menyimpan temuan dalam konteks, lalu meneruskannya ke respons. Tanggapan mengambil item hasil dan mengembalikannya sebagai tanggapan:
```
{
"data": {
"getBooks": {
"items": [
{
"id": "abcdefgh-1234-1234-1234-abcdefghijkl",
"title": "book1"
},
{
"id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"title": "book2"
},
...
]
}
}
}
```
## Konteks penyelesai
Dalam resolver, setiap langkah dalam rantai penangan harus menyadari status data dari langkah sebelumnya. Hasil dari satu handler dapat disimpan dan diteruskan ke yang lain sebagai argumen. GraphQL mendefinisikan empat argumen resolver dasar:
****
| Argumen dasar penyelesai | Deskripsi |
| --- | --- |
| obj, root, parent, dll. | Hasil dari orang tua. |
| args | Argumen yang diberikan ke bidang dalam query GraphQL. |
| context | Nilai yang diberikan kepada setiap resolver dan menyimpan informasi kontekstual penting seperti pengguna yang saat ini masuk, atau akses ke database. |
| info | Nilai yang menyimpan informasi khusus bidang yang relevan dengan kueri saat ini serta detail skema. |
Dalam AWS AppSync, argumen `[context](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html)` (ctx) dapat menampung semua data yang disebutkan di atas. Ini adalah objek yang dibuat per permintaan dan berisi data seperti kredensyal otorisasi, data hasil, kesalahan, metadata permintaan, dll. Konteksnya adalah cara mudah bagi programmer untuk memanipulasi data yang berasal dari bagian lain dari permintaan. Ambil cuplikan ini lagi:
```
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
return { operation: 'Scan' };
}
/**
* return a list of scanned post items
*/
export function response(ctx) {
return ctx.result.items;
}
```
Permintaan diberikan konteks (ctx) sebagai argumen; ini adalah status permintaan. Ini melakukan pemindaian untuk semua item dalam tabel, kemudian menyimpan hasilnya kembali dalam konteks di`result`. Konteks kemudian diteruskan ke argumen respons, yang mengakses `result` dan mengembalikan isinya.
## Permintaan dan Parsing
Saat Anda membuat kueri ke layanan GraphQL Anda, itu harus dijalankan melalui proses parsing dan validasi sebelum dieksekusi. Permintaan Anda akan diurai dan diterjemahkan ke dalam pohon sintaks abstrak. Isi pohon divalidasi dengan menjalankan beberapa algoritma validasi terhadap skema Anda. Setelah langkah validasi, simpul pohon dilintasi dan diproses. Resolver dipanggil, hasilnya disimpan dalam konteks, dan respons dikembalikan. Misalnya, ambil kueri ini:
```
query {
Person { //object type
name //scalar
age //scalar
}
}
```
Kami kembali `Person` dengan a `name` dan `age` ladang. Saat menjalankan kueri ini, pohon akan terlihat seperti ini:
![\[Hierarchical diagram showing query, Person, name, and age nodes connected by arrows.\]](http://docs.aws.amazon.com/id_id/appsync/latest/devguide/images/ast-1.png)
Dari pohon, tampak bahwa permintaan ini akan mencari root untuk `Query` dalam skema. Di dalam kueri, `Person` bidang akan diselesaikan. Dari contoh sebelumnya, kita tahu bahwa ini bisa menjadi masukan dari pengguna, daftar nilai, dll `Person` kemungkinan besar terkait dengan tipe objek yang memegang bidang yang kita butuhkan (`name`dan`age`). Setelah dua bidang anak ini ditemukan, mereka diselesaikan dalam urutan yang diberikan (`name`diikuti oleh`age`). Setelah pohon benar-benar diselesaikan, permintaan selesai dan akan dikirim kembali ke klien.