Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# GraphQL dan arsitektur AWS AppSync
**catatan**
Panduan ini mengasumsikan pengguna memiliki pengetahuan tentang gaya arsitektur REST. Kami merekomendasikan untuk meninjau ini dan topik front-end lainnya sebelum bekerja dengan GraphQL dan. AWS AppSync
GraphQL adalah bahasa query dan manipulasi untuk. APIs GraphQL menyediakan sintaks yang fleksibel dan intuitif untuk menggambarkan kebutuhan dan interaksi data. Ini memungkinkan pengembang untuk meminta apa yang dibutuhkan dan mendapatkan kembali hasil yang dapat diprediksi. Ini juga memungkinkan untuk mengakses banyak sumber dalam satu permintaan, mengurangi jumlah panggilan jaringan dan persyaratan bandwidth, sehingga menghemat masa pakai baterai dan siklus CPU yang dikonsumsi oleh aplikasi.
Membuat pembaruan data dibuat sederhana dengan mutasi, memungkinkan pengembang untuk menjelaskan bagaimana data harus berubah. GraphQL juga memfasilitasi pengaturan cepat solusi real-time melalui langganan. Semua fitur ini digabungkan, ditambah dengan alat pengembang yang kuat, menjadikan GraphQL penting untuk mengelola data aplikasi.
GraphQL adalah alternatif untuk REST. RESTful Arsitektur saat ini merupakan salah satu solusi yang lebih populer untuk komunikasi client-server. Ini berpusat pada konsep sumber daya Anda (data) yang diekspos oleh URL. Ini URLs dapat digunakan untuk mengakses dan memanipulasi data melalui operasi CRUD (membuat, membaca, memperbarui, menghapus) dalam bentuk metode HTTP seperti`GET`,`POST`, dan. `DELETE` Keuntungan REST adalah relatif sederhana untuk dipelajari dan diterapkan. Anda dapat dengan cepat mengatur RESTful APIs untuk memanggil berbagai layanan.
Namun, teknologi semakin rumit. Ketika aplikasi, alat, dan layanan mulai berskala untuk audiens di seluruh dunia, kebutuhan akan arsitektur yang cepat dan terukur sangat penting. REST memiliki banyak kekurangan ketika berhadapan dengan operasi yang dapat diskalakan. Lihat [kasus penggunaan](https://aws.amazon.com/blogs/architecture/what-to-consider-when-modernizing-apis-with-graphql-on-aws/) ini sebagai contoh.
Pada bagian berikut, kita akan meninjau beberapa konsep di sekitarnya RESTful APIs. Kami kemudian akan memperkenalkan GraphQL dan cara kerjanya.
Untuk informasi selengkapnya tentang GraphQL dan manfaat migrasi ke, lihat [panduan Keputusan AWS](https://aws.amazon.com/graphql/guide/) untuk implementasi GraphQL.
**Topics**
+ [Apa itu API](what-is-an-api.md)
+ [Apa itu REST](what-is-rest.md)
+ [Apa itu GraphQL](what-is-graphql.md)
+ [Membandingkan REST dan GraphQL](comparing-rest-graphql.md)
+ [Mengapa Menggunakan GraphQL di atas REST](why-use-graphql.md)
+ [Komponen dari GraphQL API](api-components.md)
+ [Properti tambahan GraphQL](graphql-properties.md)
# Apa itu API?
Antarmuka pemrograman aplikasi (API) mendefinisikan aturan yang harus Anda ikuti untuk berkomunikasi dengan sistem perangkat lunak lain. Pengembang mengekspos atau membuat APIs sehingga aplikasi lain dapat berkomunikasi dengan aplikasi mereka secara terprogram. Misalnya, aplikasi lembar waktu mengekspos API yang meminta nama lengkap karyawan dan rentang tanggal. Ketika menerima informasi ini, secara internal memproses lembar waktu karyawan dan mengembalikan jumlah jam kerja dalam rentang tanggal tersebut.
Anda dapat menganggap API web sebagai gateway antara klien dan sumber daya di web.
## Klien
Klien adalah pengguna yang ingin mengakses informasi dari web. Klien dapat berupa orang atau sistem perangkat lunak yang menggunakan API. Misalnya, pengembang dapat menulis program yang mengakses data cuaca dari sistem cuaca. Atau Anda dapat mengakses data yang sama dari browser Anda ketika Anda mengunjungi situs web cuaca secara langsung.
## Sumber daya
Sumber daya adalah informasi yang diberikan oleh berbagai aplikasi kepada klien mereka. Sumber daya dapat berupa gambar, video, teks, angka, atau jenis data apa pun. Mesin yang memberikan sumber daya ke klien juga disebut server. Organizations digunakan APIs untuk berbagi sumber daya dan menyediakan layanan web sambil menjaga keamanan, kontrol, dan otentikasi. Selain itu, APIs bantu mereka menentukan klien mana yang mendapatkan akses ke sumber daya internal tertentu.
# Apa itu REST?
Pada tingkat tinggi, representational State Transfer (REST) adalah arsitektur perangkat lunak yang memaksakan kondisi pada bagaimana API harus bekerja. REST awalnya dibuat sebagai pedoman untuk mengelola komunikasi pada jaringan yang kompleks seperti internet. Anda dapat menggunakan arsitektur berbasis REST untuk mendukung komunikasi berkinerja tinggi dan andal dalam skala besar. Anda dapat dengan mudah menerapkan dan memodifikasinya, membawa visibilitas dan portabilitas lintas platform ke sistem API apa pun.
Pengembang API dapat mendesain APIs menggunakan beberapa arsitektur yang berbeda. APIs yang mengikuti gaya arsitektur REST disebut REST APIs. Layanan web yang menerapkan arsitektur REST disebut layanan RESTful web. Istilah RESTful API umumnya mengacu pada RESTful web APIs. Namun, Anda dapat menggunakan istilah REST API dan RESTful API secara bergantian.
Berikut ini adalah beberapa prinsip gaya arsitektur REST:
## Antarmuka seragam
Antarmuka yang seragam sangat penting untuk desain RESTful layanan web apa pun. Ini menunjukkan bahwa server mentransfer informasi dalam format standar. Sumber daya yang diformat disebut representasi dalam REST. Format ini dapat berbeda dari representasi internal sumber daya pada aplikasi server. Misalnya, server dapat menyimpan data sebagai teks tetapi mengirimkannya dalam format representasi HTML.
Antarmuka seragam memaksakan empat kendala arsitektur:
1. Permintaan harus mengidentifikasi sumber daya. Mereka melakukannya dengan menggunakan pengenal sumber daya seragam.
1. Klien memiliki informasi yang cukup dalam representasi sumber daya untuk memodifikasi atau menghapus sumber daya jika mereka mau. Server memenuhi kondisi ini dengan mengirimkan metadata yang menjelaskan sumber daya lebih lanjut.
1. Klien menerima informasi tentang cara memproses representasi lebih lanjut. Server mencapai ini dengan mengirimkan pesan deskriptif diri yang berisi metadata tentang bagaimana klien dapat menggunakannya dengan sebaik-baiknya.
1. Klien menerima informasi tentang semua sumber daya terkait lainnya yang mereka butuhkan untuk menyelesaikan tugas. Server mencapai ini dengan mengirimkan hyperlink dalam representasi sehingga klien dapat secara dinamis menemukan lebih banyak sumber daya.
## Tanpa kewarganegaraan
Dalam arsitektur REST, statelessness mengacu pada metode komunikasi di mana server menyelesaikan setiap permintaan klien secara independen dari semua permintaan sebelumnya. Klien dapat meminta sumber daya dalam urutan apa pun, dan setiap permintaan tidak memiliki kewarganegaraan atau terisolasi dari permintaan lain. Kendala desain REST API ini menyiratkan bahwa server dapat sepenuhnya memahami dan memenuhi permintaan setiap saat.
## Sistem berlapis
Dalam arsitektur sistem berlapis, klien dapat terhubung ke perantara resmi lainnya antara klien dan server, dan masih akan menerima tanggapan dari server. Server juga dapat meneruskan permintaan ke server lain. Anda dapat merancang layanan RESTful web Anda untuk berjalan di beberapa server dengan beberapa lapisan seperti keamanan, aplikasi, dan logika bisnis, bekerja sama untuk memenuhi permintaan klien. Lapisan ini tetap tidak terlihat oleh klien.
## Cacheability
RESTful layanan web mendukung caching, yang merupakan proses menyimpan beberapa tanggapan pada klien atau pada perantara untuk meningkatkan waktu respons server. Misalnya, Anda mengunjungi situs web yang memiliki gambar header dan footer umum di setiap halaman. Setiap kali Anda mengunjungi halaman situs web baru, server harus mengirim ulang gambar yang sama. Untuk menghindari hal ini, klien menyimpan atau menyimpan gambar-gambar ini setelah respons pertama dan kemudian menggunakan gambar langsung dari cache. RESTful layanan web mengontrol caching dengan menggunakan respons API yang mendefinisikan diri mereka sebagai cacheable atau noncacheable.
## Apa itu RESTful API?
RESTful API adalah antarmuka yang digunakan dua sistem komputer untuk bertukar informasi dengan aman melalui internet. Sebagian besar aplikasi bisnis harus berkomunikasi dengan aplikasi internal dan pihak ketiga lainnya untuk melakukan berbagai tugas. Misalnya, untuk menghasilkan slip gaji bulanan, sistem akun internal Anda harus berbagi data dengan sistem perbankan pelanggan Anda untuk mengotomatiskan faktur dan berkomunikasi dengan aplikasi lembar waktu internal. RESTful APIs mendukung pertukaran informasi ini karena mereka mengikuti standar komunikasi perangkat lunak yang aman, andal, dan efisien.
## Bagaimana cara RESTful APIs kerjanya?
Fungsi dasar dari sebuah RESTful API adalah sama dengan browsing internet. Klien menghubungi server dengan menggunakan API saat membutuhkan sumber daya. Pengembang API menjelaskan bagaimana klien harus menggunakan REST API dalam dokumentasi API aplikasi server. Ini adalah langkah-langkah umum untuk setiap panggilan REST API:
1. Klien mengirimkan permintaan ke server. Klien mengikuti dokumentasi API untuk memformat permintaan dengan cara yang dipahami server.
1. Server mengotentikasi klien dan mengonfirmasi bahwa klien memiliki hak untuk membuat permintaan itu.
1. Server menerima permintaan dan memprosesnya secara internal.
1. Server mengembalikan respons ke klien. Respons berisi informasi yang memberi tahu klien apakah permintaan berhasil. Tanggapan tersebut juga mencakup informasi apa pun yang diminta klien.
Permintaan REST API dan detail respons sedikit berbeda tergantung pada bagaimana pengembang API mendesain API.
# Apa itu GraphQL?
GraphQL adalah bahasa query APIs untuk dan runtime untuk mengeksekusi query tersebut. GraphQL memungkinkan klien untuk meminta persis data yang mereka butuhkan, memberikan alternatif yang lebih fleksibel dan efisien untuk REST dalam banyak skenario. Tidak seperti REST, yang bergantung pada titik akhir yang telah ditentukan sebelumnya, GraphQL menggunakan titik akhir tunggal di mana klien dapat menentukan persyaratan data mereka dalam bentuk kueri dan mutasi.
Lihat [Komponen GraphQL API untuk informasi selengkapnya tentang bagaimana APIs GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/api-components.html) terstruktur.
# Membandingkan REST dan GraphQL
APIs (Application Programming Interfaces) memainkan peran penting dalam memfasilitasi pertukaran data antar aplikasi. Seperti yang dinyatakan sebelumnya, dua pendekatan menonjol untuk merancang APIs telah muncul: GraphQL dan REST. Meskipun keduanya melayani tujuan mendasar untuk memungkinkan komunikasi client-server, keduanya berbeda secara signifikan dalam implementasi dan kasus penggunaannya.
GraphQL dan REST berbagi beberapa karakteristik utama:
1. **Model Client-Server**: Keduanya menggunakan arsitektur client-server untuk pertukaran data.
1. **Tanpa kewarganegaraan**: Tidak ada yang menyimpan informasi sesi klien di antara permintaan.
1. **Berbasis HTTP**: Keduanya biasanya menggunakan HTTP sebagai protokol komunikasi yang mendasarinya.
1. **Desain Berorientasi Sumber Daya**: Keduanya merancang pertukaran data mereka di sekitar sumber daya, yang mengacu pada data atau objek apa pun yang dapat diakses dan dimanipulasi klien melalui API.
1. **Fleksibilitas Format Data**: JSON adalah format pertukaran data yang paling umum digunakan di keduanya, meskipun format lain seperti XML/HTML juga didukung.
1. **Bahasa dan Database Agnostik**: Keduanya dapat bekerja dengan bahasa pemrograman atau struktur basis data apa pun, membuatnya sangat interoperable.
1. **Caching Support**: Keduanya mendukung caching, memungkinkan klien dan server untuk menyimpan data yang sering diakses untuk meningkatkan kinerja.
Sambil berbagi beberapa prinsip dasar, GraphQL dan REST berbeda secara signifikan dalam pendekatan mereka terhadap desain API dan pengambilan data:
1. **Minta Struktur dan Pengambilan Data**
REST menggunakan metode HTTP yang berbeda (GET, POST, PUT, DELETE) untuk melakukan operasi pada sumber daya. Ini sering membutuhkan beberapa titik akhir untuk sumber daya yang berbeda, yang dapat menyebabkan inefisiensi dalam pengambilan data. Misalnya, menjalankan operasi GET untuk mengambil data pengguna dapat menyebabkan pengambilan data yang berlebihan atau kurang diambil. Untuk mendapatkan data yang benar, pemotongan atau beberapa operasi dapat dipanggil.
GraphQL menggunakan endpoint tunggal untuk semua operasi. Itu bergantung pada kueri untuk mengambil data dan mutasi untuk memodifikasi data. Klien dapat menggunakan kueri untuk mengambil persis data yang mereka butuhkan dalam satu permintaan, yang mengurangi overhead jaringan dengan meminimalkan transfer data.
1. **Skema sisi server**
REST tidak memerlukan skema sisi server, meskipun skema dapat didefinisikan secara opsional untuk desain dan dokumentasi API yang efisien.
GraphQL menggunakan skema sisi server yang diketik dengan kuat untuk menentukan layanan data dan data. Skema, ditulis dalam GraphQL Schema Definition Language (SDL), mencakup jenis objek dan bidang untuk setiap objek dan fungsi resolver sisi server yang menentukan operasi untuk setiap bidang.
1. **Pembuatan Versi**
REST sering menyertakan pembuatan versi di URL, yang dapat menyebabkan pemeliharaan beberapa versi API secara bersamaan. Pembuatan versi tidak wajib tetapi dapat membantu mencegah perubahan yang melanggar.
GraphQL mempromosikan evolusi API yang berkelanjutan tanpa pembuatan versi eksplisit dengan memerlukan kompatibilitas mundur. Bidang yang dihapus mengembalikan pesan kesalahan, sementara tag penghentian menghapus bidang lama dan mengembalikan pesan peringatan.
1. **Penanganan Kesalahan**
REST diketik dengan lemah, membutuhkan penanganan kesalahan untuk dibangun ke dalam kode sekitarnya. Ini mungkin tidak secara otomatis mengidentifikasi kesalahan terkait tipe (misalnya, mengurai angka sebagai teks).
Sebaliknya, GraphQL diketik dengan kuat dan memerlukan definisi skema yang komprehensif. Ini memungkinkan layanan Anda untuk secara otomatis mengidentifikasi banyak kesalahan permintaan dengan tingkat detail yang tinggi.
1. **Kasus Penggunaan**
REST lebih cocok untuk:
+ Aplikasi yang lebih kecil dengan persyaratan data yang kurang kompleks.
+ Skenario di mana data dan operasi digunakan sama oleh semua klien.
+ Aplikasi tanpa kebutuhan kueri data yang kompleks.
GraphQL lebih cocok untuk:
+ Skenario dengan bandwidth terbatas, di mana meminimalkan permintaan dan tanggapan sangat penting.
+ Aplikasi dengan beberapa sumber data yang perlu digabungkan pada satu titik akhir.
+ Kasus di mana permintaan klien bervariasi secara signifikan dan mengharapkan struktur respons yang berbeda.
Perhatikan bahwa dimungkinkan untuk menggunakan GraphQL dan APIs REST dalam satu aplikasi untuk area fungsionalitas yang berbeda. Selanjutnya, Anda dapat memutakhirkan RESTful API untuk menyertakan kemampuan GraphQL tanpa penulisan ulang yang lengkap. Lihat [Cara membuat resolver GraphQL AWS untuk](https://aws.amazon.com/graphql/resolvers/) sumber data sebagai contoh.
# Mengapa Menggunakan GraphQL di atas REST?
REST adalah salah satu landasan gaya arsitektur web. APIs Namun, ketika dunia menjadi lebih saling berhubungan, kebutuhan untuk mengembangkan aplikasi yang kuat dan terukur akan menjadi masalah yang lebih mendesak. Sementara REST sering digunakan untuk membangun web APIs, ada beberapa kelemahan berulang untuk RESTful implementasi yang telah diidentifikasi:
1. **Permintaan data**: Menggunakan RESTful APIs, Anda biasanya akan meminta data yang Anda butuhkan melalui titik akhir. Masalah muncul ketika Anda memiliki data yang mungkin tidak begitu rapi dikemas. Data yang Anda butuhkan mungkin berada di belakang beberapa lapisan abstraksi, dan satu-satunya cara untuk mengambil data adalah dengan menggunakan beberapa titik akhir, yang berarti membuat beberapa permintaan untuk mengekstrak semua data.
1. **Overfetching dan underfetching**: Untuk menambah masalah beberapa permintaan, data dari setiap titik akhir didefinisikan secara ketat, artinya Anda akan mengembalikan data apa pun yang ditentukan untuk API itu, bahkan jika Anda tidak menginginkannya secara teknis.
Hal ini dapat mengakibatkan *pengambilan berlebihan*, yang berarti permintaan kami mengembalikan data yang berlebihan. Misalnya, katakanlah Anda meminta data personel perusahaan dan ingin mengetahui nama-nama karyawan di departemen tertentu. Titik akhir yang mengembalikan data akan berisi nama, tetapi mungkin juga berisi data lain seperti jabatan atau tanggal lahir. Karena API sudah diperbaiki, Anda tidak bisa hanya meminta nama saja; sisa data menyertainya.
Situasi sebaliknya di mana kita tidak mengembalikan cukup data disebut *under-fetching*. Untuk mendapatkan semua data yang diminta, Anda mungkin harus membuat beberapa permintaan ke layanan. Bergantung pada bagaimana data disusun, Anda dapat mengalami kueri yang tidak efisien yang mengakibatkan masalah seperti masalah n\$11 yang ditakuti.
1. **Iterasi pengembangan lambat**: Banyak pengembang menyesuaikannya RESTful APIs agar sesuai dengan aliran aplikasi mereka. Namun, seiring berkembangnya aplikasi mereka, baik bagian depan maupun backend mungkin memerlukan perubahan ekstensif. Akibatnya, APIs mungkin tidak lagi sesuai dengan bentuk data dengan cara yang efisien atau berdampak. Ini menghasilkan iterasi produk yang lebih lambat karena kebutuhan akan modifikasi API.
1. **Kinerja dalam skala besar**: Karena masalah peracikan ini, ada banyak area di mana skalabilitas akan terpengaruh. Kinerja di sisi aplikasi mungkin terpengaruh karena permintaan Anda akan mengembalikan terlalu banyak data atau terlalu sedikit (menghasilkan lebih banyak permintaan). Kedua situasi menyebabkan ketegangan yang tidak perlu pada jaringan yang mengakibatkan kinerja yang buruk. Di sisi pengembang, kecepatan pengembangan dapat dikurangi karena Anda APIs sudah diperbaiki dan tidak lagi sesuai dengan data yang mereka minta.
Nilai jual GraphQL adalah untuk mengatasi kekurangan REST. Berikut adalah beberapa solusi utama yang ditawarkan GraphQL kepada pengembang:
1. **Titik akhir tunggal**: GraphQL menggunakan titik akhir tunggal untuk menanyakan data. Tidak perlu membangun beberapa APIs agar sesuai dengan bentuk data. Ini menghasilkan lebih sedikit permintaan melalui jaringan.
1. **Pengambilan**: GraphQL memecahkan masalah abadi dari pengambilan berlebihan dan kurang hanya dengan mendefinisikan data yang Anda butuhkan. GraphQL memungkinkan Anda membentuk data agar sesuai dengan kebutuhan Anda sehingga Anda hanya menerima apa yang Anda minta.
1. **Abstraksi**: APIs GraphQL berisi beberapa komponen dan sistem yang menggambarkan data menggunakan standar agnostik bahasa. Dengan kata lain, bentuk dan struktur data distandarisasi sehingga bagian depan dan backend tahu bagaimana data akan dikirim melalui jaringan. Hal ini memungkinkan pengembang di kedua ujungnya untuk bekerja dengan sistem GraphQL dan tidak di sekitar mereka.
1. **Iterasi cepat**: Karena standarisasi data, perubahan pada satu ujung pengembangan mungkin tidak diperlukan di sisi lain. Misalnya, perubahan presentasi frontend mungkin tidak menghasilkan perubahan backend yang ekstensif karena GraphQL memungkinkan spesifikasi data untuk dimodifikasi dengan mudah. Anda cukup menentukan atau memodifikasi bentuk data agar sesuai dengan kebutuhan aplikasi saat tumbuh. Ini menghasilkan pekerjaan pengembangan yang kurang potensial.
Ini hanya beberapa manfaat dari GraphQL. Di beberapa bagian berikutnya, Anda akan mempelajari bagaimana GraphQL terstruktur dan properti yang menjadikannya alternatif unik untuk REST.
# 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.
# Properti tambahan GraphQL
GraphQL terdiri dari beberapa prinsip desain untuk menjaga kesederhanaan dan ketahanan dalam skala.
## Deklaratif
GraphQL bersifat deklaratif, yang berarti pengguna akan mendeskripsikan (membentuk) data dengan hanya mendeklarasikan bidang yang ingin mereka kueri. Respons hanya akan mengembalikan data untuk properti ini. Misalnya, berikut adalah operasi yang mengambil `Book` objek dalam tabel DynamoDB dengan nilai ISBN 13 dari: `id` *9780199536061*
```
{
getBook(id: "9780199536061") {
name
year
author
}
}
```
Respons akan mengembalikan bidang di payload (`name`,`year`, dan`author`) dan tidak ada yang lain:
```
{
"data": {
"getBook": {
"name": "Anna Karenina",
"year": "1878",
"author": "Leo Tolstoy",
}
}
}
```
Karena prinsip desain ini, GraphQL menghilangkan masalah abadi dari pengambilan berlebihan dan kekurangan yang ditangani REST dalam sistem yang APIs kompleks. Ini menghasilkan pengumpulan data yang lebih efisien dan peningkatan kinerja jaringan.
## Hirarkis
GraphQL fleksibel karena data yang diminta dapat dibentuk oleh pengguna agar sesuai dengan kebutuhan aplikasi. Data yang diminta selalu mengikuti jenis dan sintaks properti yang ditentukan dalam GraphQL API Anda. Misalnya, cuplikan berikut menunjukkan `getBook` operasi dengan lingkup bidang baru yang disebut `quotes` yang mengembalikan semua string kutipan tersimpan dan halaman yang ditautkan ke: `Book` *9780199536061*
```
{
getBook(id: "9780199536061") {
name
year
author
quotes {
description
page
}
}
}
```
Menjalankan query ini mengembalikan hasil sebagai berikut:
```
{
"data": {
"getBook": {
"name": "Anna Karenina",
"year": "1878",
"author": "Leo Tolstoy",
"quotes": [
{
"description": "The highest Petersburg society is essentially one: in it everyone knows everyone else, everyone even visits everyone else.",
"page": 135
},
{
"description": "Happy families are all alike; every unhappy family is unhappy in its own way.",
"page": 1
},
{
"description": "To Konstantin, the peasant was simply the chief partner in their common labor.",
"page": 251
}
]
}
}
}
```
Seperti yang Anda lihat, `quotes` bidang yang ditautkan ke buku yang diminta dikembalikan sebagai array dalam format yang sama yang dijelaskan oleh kueri kami. Meskipun tidak ditampilkan di sini, GraphQL memiliki keuntungan tambahan karena tidak khusus tentang lokasi data yang diambilnya. `Books`dan `quotes` dapat disimpan secara terpisah, tetapi GraphQL akan tetap mengambil informasi selama asosiasi ada. Ini berarti kueri Anda dapat mengambil banyak data mandiri dalam satu permintaan.
## Introspektif
GraphQL adalah mendokumentasikan diri, atau introspektif. Ini mendukung beberapa operasi bawaan yang memungkinkan pengguna untuk melihat jenis dan bidang yang mendasarinya dalam skema. Misalnya, berikut adalah `Foo` tipe dengan `description` bidang `date` dan:
```
type Foo {
date: String
description: String
}
```
Kita bisa menggunakan `_type` operasi untuk menemukan metadata pengetikan di bawah skema:
```
{
__type(name: "Foo") {
name # returns the name of the type
fields { # returns all fields in the type
name # returns the name of each field
type { # returns all types for each field
name # returns the scalar type
}
}
}
}
```
Ini akan mengembalikan respons:
```
{
"__type": {
"name": "Foo", # The type name
"fields": [
{
"name": "date", # The date field
"type": { "name": "String" } # The date's type
},
{
"name": "description", # The description field
"type": { "name": "String" } # The description's type
},
]
}
}
```
Fitur ini dapat digunakan untuk mengetahui jenis dan bidang apa yang didukung skema GraphQL tertentu. GraphQL mendukung berbagai macam operasi introspektif ini. Untuk informasi lebih lanjut, lihat [Introspeksi](https://graphql.org/learn/introspection/).
## Pengetikan yang kuat
GraphQL mendukung pengetikan yang kuat melalui jenis dan sistem bidangnya. Ketika Anda mendefinisikan sesuatu dalam skema Anda, itu harus memiliki tipe yang dapat divalidasi sebelum runtime. Itu juga harus mengikuti spesifikasi sintaks GraphQL. Konsep ini tidak berbeda dengan pemrograman dalam bahasa lain. Misalnya, inilah `Foo` tipe dari sebelumnya:
```
type Foo {
date: String
description: String
}
```
Kita bisa melihat bahwa `Foo` adalah objek yang akan dibuat. Di dalam instance`Foo`, akan ada `date` dan `description` field, keduanya tipe `String` primitif (skalar). Secara sintaksis, kita melihat bahwa `Foo` dideklarasikan, dan bidangnya ada di dalam ruang lingkupnya. Kombinasi pemeriksaan tipe dan sintaks logis ini memastikan bahwa GraphQL API Anda ringkas dan terbukti dengan sendirinya. [Spesifikasi pengetikan dan sintaks GraphQL dapat ditemukan di sini.](https://spec.graphql.org/)