Berita teknologi terbaru, didukung oleh insight dari pakar
Tetap terinformasi tentang tren industri yang paling penting—dan menarik—tentang AI, otomatisasi, data, dan di luarnya dengan buletin Think. Lihat Pernyataan Privasi IBM®.
Apa itu GraphQL?
diterbitkan 5 November 2024
GraphQL adalah bahasa kueri sumber terbuka dan runtime sisi server yang menentukan bagaimana klien harus berinteraksi dengan antarmuka pemrograman aplikasi (API).
GraphQL menawarkan alternatif yang efisien dan lebih fleksibel untuk transfer status representasional (REST) dan API RESTful dan menangani beberapa keterbatasan REST. Misalnya, memberikan kemampuan untuk menargetkan sumber daya secara lebih akurat dengan satu kueri.
GraphQL menggunakan sintaksis intuitif yang memungkinkan klien mengirim satu kueri GraphQL ke suatu API dan menerima data persis yang dibutuhkan (alih-alih mengakses titik akhir kompleks yang memiliki banyak parameter). Pengambilan data yang lebih efisien ini dapat meningkatkan kinerja sistem dan kemudahan penggunaan bagi pengembang.
Hal ini membuat GraphQL sangat berguna untuk membangun API di lingkungan yang kompleks dengan persyaratan front-end yang berubah cepat. Baik API REST maupun GraphQL secara inheren tidak lebih unggul; mereka adalah alat yang berbeda yang cocok untuk tugas yang berbeda.
Pada awal tahun 2010, Facebook mengalami pertumbuhan dan transformasi besar-besaran. Namun, basis pengguna yang terus bertambah dan lingkungan aplikasi seluler yang makin kompleks membuat pendekatan RESTful yang ada saat ini, yang membutuhkan beberapa perjalanan balik ke titik akhir API yang berbeda untuk mengambil semua data kueri yang diperlukan, tidak berkelanjutan.
REST API tidak dilengkapi dengan baik untuk menangani antarmuka pengguna yang kompleks dan berbasis data, dan sering mengalami masalah latensi dan inefisiensi data, terutama untuk pengguna mobile dengan paket data yang terbatas atau mahal.
Menanggapi tantangan ini, para teknisi Facebook mengembangkan GraphQL (bersama dengan platform aplikasi satu halaman React), merilisnya sebagai solusi sumber terbuka pada tahun 2015. Pada akhirnya, Facebook memindahkan layanan ke GraphQL Foundation, yang terdiri dari perusahaan anggota seperti AWS, Gatsby, Intuit dan IBM pada tahun 2018.
Fitur pengambilan data deklaratif dari arsitektur GraphQL berkisar pada beberapa komponen dan proses utama, yang masing-masing memainkan peran unik dalam penanganan dan pemrosesan data.
Hal ini termasuk:
- Skema
- Resolver
- Pertanyaan
- Mutasi
Skema
GraphQL bergantung pada sistem jenis yang kuat tempat semua jenis data direkam dalam bahasa definisi skema GraphQL (SDL). Skema dengan jenis menentukan jenis data yang dapat dikueri dalam API dan hubungan antara jenis dan operasi yang tersedia bagi pengguna.
Dengan kata lain, skema mendefinisikan kemampuan API dan bentuk data yang dapat digunakan klien untuk berinteraksi. Konfigurasi skema ini pada akhirnya menentukan cara API dapat digunakan. Saat kueri masuk, skema digunakan untuk validasi permintaan dan GraphQL API hanya mengeksekusi kueri yang divalidasi.
Resolver
Setiap bidang dalam skema didukung oleh sebuah resolver yang mengisi data dan menentukan respons terhadap sekumpulan bidang. Resolver—yang dapat mengambil data dari database, layanan cloud atau hampir semua sumber lainnya—memberikan instruksi untuk mengubah operasi GraphQL (misalnya, kueri, mutasi, atau langganan) menjadi data.
Ketika bidang kueri dimulai, sistem akan membuat panggilan ke resolver yang sesuai untuk menghasilkan nilai berikutnya. Jika suatu bidang menghasilkan nilai skalar (misalnya string atau angka), eksekusi selesai. Jika suatu bidang menghasilkan nilai objek, kueri akan berisi lebih banyak bidang untuk objek tersebut. Proses ini terus berlanjut sampai hanya bidang skalar yang tersisa.
Resolver juga memfasilitasi pemformatan data dan membantu sistem menyatukan informasi dari berbagai sumber data.
Pertanyaan
Kueri data adalah permintaan yang dibuat oleh klien ke server GraphQL; kueri ini menentukan data apa yang ingin diambil oleh klien. Kueri didefinisikan dalam tipe kueri, yang merupakan objek khusus dalam kode yang mendefinisikan titik masuk tingkat atas untuk setiap permintaan yang dapat dieksekusi oleh klien terhadap server. Setiap jenis kueri juga mendefinisikan nama dan tipe pengembalian untuk setiap titik masuk.
Ketika sebuah kueri masuk, GraphQL memvalidasinya terhadap definisi skema dan, dengan menganggap kueri tersebut valid, mengeksekusinya. Struktur kueri biasanya mencerminkan struktur data respons, sehingga kebutuhan data menjadi eksplisit dan dapat diprediksi.
Mutasi
Mutasi adalah operasi GraphQL yang membuat, memperbarui, atau menghapus data di server. Operasi ini serupa dengan operasi POST, PUT, PATCH, dan DELETE dalam RESTful API. Meskipun pengguna dapat mengakses beberapa kueri tanpa autentikasi, mutasi selalu membutuhkan autentikasi (misalnya, dengan menggunakan token API).
Mirip dengan cara kerja kueri, mutasi GraphQL divalidasi terhadap skema dan definisinya. Setelah mutasi divalidasi dan dimulai, server mengembalikan respons JSON.
Meskipun GraphQL API telah muncul sebagai alternatif yang lebih efisien dan fleksibel, REST telah lama menjadi standar untuk arsitektur API. REST adalah gaya arsitektur terstruktur untuk aplikasi hypermedia berjaringan yang dirancang menggunakan protokol komunikasi client/server yang bersifat stateless dan dapat di-cache (umumnya HTTP).
Pilihan antara GraphQL vs. REST pada dasarnya bergantung pada tool yang paling tepat untuk memenuhi kebutuhan tertentu. Baik GraphQL maupun REST memungkinkan client berkomunikasi dengan server dan meminta data, tetapi terdapat sejumlah perbedaan utama yang menjelaskan semakin luasnya penggunaan sistem GraphQL.
REST API dirancang berdasarkan sumber daya (misalnya, semua jenis objek, data, atau layanan yang dapat diakses oleh klien) dan bekerja dengan memiliki titik akhir (URL) yang berbeda untuk setiap sumber daya. REST API menggunakan struktur data tetap untuk menentukan bentuk dan ukuran sumber daya yang mereka sediakan untuk klien.
Ketika klien meminta sumber daya, server mengirimkan kembali kumpulan data lengkap dengan semua data yang terkait dengan sumber daya tersebut. Jika hanya membutuhkan sebagian data, klien masih menerima semua data (over-fetching); jika membutuhkan data yang mencakup banyak sumber daya, klien sering harus melakukan banyak panggilan API karena pengambilan data yang tidak memadai dari permintaan awal (under-fetching).
Namun, GraphQL menggunakan satu titik akhir yang menyediakan deskripsi data yang lengkap dan mudah dipahami. Kueri GraphQL dapat mengakses properti sumber daya dan mengikuti referensi antar-sumber daya. Hal ini memungkinkan klien untuk mendapatkan semua data yang dibutuhkannya dari satu muatan permintaan API dan menghindari masalah over-fetching dan under-fetching.
Dalam arsitektur RESTful, perubahan struktur data sering kali mengharuskan tim mengubah versi API untuk mencegah kesalahan sistem dan gangguan layanan bagi pengguna.
Ini berarti developer harus membuat titik akhir baru setiap kali mereka mengubah struktur, sehingga menghasilkan beberapa versi API dan mempersulit proses pemeliharaan.
GraphQL menghilangkan kebutuhan akan pembuatan versi karena klien dapat menentukan kebutuhan mereka dalam kueri. Jika bidang baru ditambahkan ke server, klien yang tidak membutuhkan bidang tersebut tidak akan terpengaruh. Sebaliknya, jika bidang tidak digunakan lagi, klien dapat terus meminta hingga mereka memperbarui kuerinya.
REST API menggunakan kode status HTTP untuk menunjukkan status/keberhasilan permintaan. Setiap kode status memiliki arti tertentu. Permintaan yang berhasil mengembalikan kode status 200, sementara kesalahan klien mungkin mengembalikan kode status 400 dan kesalahan server dapat mengembalikan kode status 500.
GraphQL menangani kesalahan secara berbeda. Setiap permintaan, terlepas dari apakah permintaan tersebut menghasilkan kesalahan, mengembalikan kode status 200 OK. Kesalahan tidak dikomunikasikan menggunakan kode status HTTP; sebaliknya, sistem mengomunikasikan kesalahan dalam badan respons bersama dengan data.
Pendekatan ini mengharuskan klien mengurai badan respons untuk menentukan apakah permintaan berhasil, yang dapat membuat debugging API GraphQL sedikit menantang.
REST tidak memiliki dukungan bawaan untuk pembaruan real-time. Jika aplikasi web atau seluler membutuhkan fungsi real-time dengan REST API, developer biasanya harus mengimplementasikan teknik seperti polling panjang (yaitu klien berulang kali melakukan polling pada server untuk mendapatkan data baru), peristiwa yang dikirim server, dan WebSockets, yang dapat menambah kerumitan pada aplikasi.
Namun, graphQL menyertakan dukungan bawaan untuk pembaruan real-time melalui langganan. Langganan mempertahankan koneksi yang stabil ke server, memungkinkan server mendorong pembaruan ke klien setiap kali peristiwa tertentu terjadi dan memungkinkan klien untuk tetap mengikuti data API yang relevan.
Ekosistem REST sudah mapan dengan berbagai macam alat, pustaka, kerangka kerja, dan tutorial yang tersedia bagi para pengembang. Namun, bekerja dengan REST API sering kali mengharuskan tim untuk menavigasi beberapa titik akhir dan memahami konvensi dan pola unik dari setiap API.
GraphQL relatif baru, tetapi ekosistem GraphQL telah berkembang pesat sejak diperkenalkan, dengan berbagai alat dan pustaka yang tersedia untuk pengembangan layanan frontend dan backend.
Alat seperti GraphiQL, Apollo Studio, dan GraphQL Playground menyediakan lingkungan pengembangan terintegrasi dalam peramban (IDE) yang tangguh untuk menjelajahi dan menguji API GraphQL. Selain itu, GraphQL memiliki dukungan yang kuat untuk pembuatan kode, yang dapat menyederhanakan pengembangan sisi klien.
REST API mengandalkan mekanisme penyimpanan cache HTTP seperti ETag dan header yang dimodifikasi terakhir. Meskipun efektif, strategi penyimpanan cache bisa jadi rumit untuk diterapkan dan mungkin tidak secara konsisten mengoptimalkan kinerja untuk semua contoh penggunaan.
API GraphQL bisa lebih menantang untuk di-cache karena sifat dinamis dari kueri. Namun, penggunaan kueri yang bertahan, cache respons, dan cache sisi server dapat mengurangi tantangan ini dan memberikan strategi penyimpanan cache yang efisien untuk arsitektur GraphQL.
Sejak transisi GraphQL ke GraphQL Foundation, para pengembang telah membuat implementasi untuk berbagai bahasa pemrograman, termasuk JavaScript, Python, Ruby, dan PHP, di antaranya. API GraphQL telah diadopsi oleh banyak sekali bisnis, seperti Github, Pinterest, PayPal, Shopify, Airbnb, dan banyak lagi, yang memungkinkan lebih banyak klien menyederhanakan spesifikasi data, mengurangi transmisi data jaringan yang berlebihan atau tidak memadai, dan meningkatkan kemampuan pengambilan data secara keseluruhan.1
Terlebih lagi, perusahaan dan pengembang mendorong federasi terbuka arsitektur GraphQL. Dalam iterasi saat ini, federasi GraphQL mengambil layanan GraphQL yang terpisah dan menggabungkannya ke dalam satu API GraphQL, yang berfungsi sebagai titik masuk ke semua data backend yang mendasarinya dan memfasilitasi pengambilan data permintaan tunggal. Namun, implementasi federasi hanya berlaku untuk satu vendor saja.
Sebagai tanggapan, para pendukung GraphQL menganjurkan federasi demokratis, yang memfasilitasi agregasi data dari API GraphQL dan API non-GraphQL, bukan agregasi eksklusif GraphQL.2
Sumber daya
Bangun API yang aman dan fleksibel lebih cepat dengan lebih sedikit kode, menyatukan data untuk mempercepat pengembangan dan inovasi.
Hubungkan, otomatis, dan pecahkan silo untuk Integrasi inovasi dan kecepatan dengan integrasi yang aman dan terpadu.
Maksimalkan nilai hybrid cloud di era AI agen. Mempercepat transformasi, memodernisasi aplikasi, dan mengotomatiskan TI untuk mendorong efisiensi, keberlanjutan, dan inovasi yang lebih cepat.
Catatan kaki
1 IBM mengakuisisi startup GraphQL StepZen untuk memperkuat kemampuan API Management, TechCrunch, 8 Februari 2023
2 Mengapa GraphQL Membutuhkan Pendekatan Federasi Terbuka, The New Stack, 16 November 2023