API, singkatan dari Application Programming Interface, adalah perantara perangkat lunak yang memungkinkan dua aplikasi berkomunikasi satu sama lain. Itu bisa berupa server, klien, atau aplikasi yang berbicara dengan server. Garis waktu di bawah ini mengilustrasikan bagaimana API telah berkembang selama bertahun-tahun, dan meletakkan dasar yang bagus tentang bagaimana API dapat dibangun. REST tetap menjadi alat populer untuk membangun API. Namun, pada tahun 2012, Facebook menginginkan sesuatu yang berbeda dari REST, dan saat itulah GraphQL (Graph Query Language) diperkenalkan.
Apa itu REST?
REST adalah Representational State Transfer API, artinya setiap sumber daya memiliki titik akhir sendiri. Awalnya, itu adalah disertasi yang diterbitkan oleh Roy Fielding pada tahun 2000 dan dipopulerkan oleh perusahaan seperti Twitter pada tahun 2006. REST adalah konsep arsitektur untuk perangkat lunak berbasis jaringan. Ini tidak memiliki seperangkat alat resmi, tidak ada spesifikasi, tidak terlalu peduli jika Anda menggunakan HTTP, AMQP, dll., dan dirancang untuk memisahkan API dari klien.
Tantangan Utama dengan REST API
REST API terkadang membutuhkan Beberapa Perjalanan Pulang Pergi. Ini berlaku ketika kita perlu menampilkan beberapa data yang harus dikonsumsi dari titik akhir yang berbeda, dan mengkonsumsi data hanya dari satu titik akhir saja tidak cukup. Tabel di bawah ini menggambarkan tiga titik akhir:
| DAPATKAN /pengguna | Daftar semua pengguna |
| DAPATKAN /pengguna/:id | Dapatkan pengguna tunggal dengan id :id |
| DAPATKAN /pengguna/:id/proyek | Dapatkan semua proyek dari satu pengguna |
Bagaimana jika di aplikasi klien, kita perlu mengambil proyek yang terkait dengan pengguna tertentu dan beberapa tugas yang mungkin juga terkait dengan proyek itu sendiri? Haruskah tim back-end mengembangkan sesuatu yang ekstra? Ada kemungkinan cara berikut untuk melakukannya:
- Untuk memasukkan kueri, dan kemudian mengembalikan tugas ke setiap proyek: GET /users/:id/projects?include=tasks
- Untuk memiliki titik akhir terpisah, proyek sumber daya, dan meminta aplikasi klien memfilter kueri berdasarkan id pengguna: GET /projects?userid=:id&include=tasks
- Untuk memasukkan semua data yang mungkin terkait dengan pengguna dalam satu titik akhir: GET /tasks?userid=:id
Over-fetching dan Under-fetching. Ketika ada kebutuhan untuk mengembalikan terlalu banyak data, aplikasi klien tidak memerlukan semua data itu. Pelanggan tidak senang jika mereka diminta untuk mengunduh informasi tambahan yang sebenarnya tidak mereka butuhkan. Di sisi lain, dengan mengurangi tingkat informasi di server, masalah under-fetching dapat dialami, dan titik akhir dan sumber daya tambahan lain di server untuk mendapatkan data itu diperlukan. Solusinya adalah: GET /users?fields=firstname,lastname.
Kesulitan dalam membuat versi dan mencela bidang yang tidak diperlukan untuk rilis baru . Sulit untuk mempertahankan REST API saat ia tumbuh seiring waktu, dan persyaratan yang berbeda diminta untuk mendukung berbagai versi aplikasi dan beberapa klien. Jadi, biasanya v1 dibiarkan apa adanya, dan v2 dibuat dengan struktur data yang lebih baru. Dengan GraphQL, itu bisa dilakukan tanpa kontrol versi. GraphQL hanya mengembalikan data yang diminta secara eksplisit, sehingga kemampuan baru dapat ditambahkan melalui tipe baru dan bidang baru pada tipe tersebut tanpa membuat perubahan yang mengganggu. Hal ini menyebabkan praktik umum untuk terus menghindari kerusakan perubahan dan menyajikan API tanpa versi.
Data yang tidak dapat diprediksi . Dengan REST tidak diketahui data apa yang akan dikembalikan dari server, field apa, berapa banyak, dll. Dengan GraphQL, klien meminta field tertentu untuk dikembalikan. Tidak masalah apakah itu kueri atau mutasi – Anda mengendalikan apa yang akan dikembalikan.
Apa itu GraphQL?
GraphQL adalah konsep yang lebih baru, dirilis oleh Facebook secara publik pada tahun 2015. GraphQL, sebagai cara baru untuk meminta data dari server, adalah bahasa kueri, spesifikasi, dan kumpulan alat yang dirancang untuk beroperasi melalui satu titik akhir melalui HTTP, mengoptimalkan kinerja dan fleksibilitas.
Tabel ini membandingkan GraphQL dan REST sebagai dua pendekatan yang membangun API. Berbicara secara umum, ini tidak dapat dianggap sebagai perbandingan apel-ke-apel, tetapi lebih seperti paralel oranye-ke-apel karena REST adalah standar konvensional untuk merencanakan API, dan GraphQL adalah bahasa kueri yang membantu memecahkan masalah dengan API . Namun, keduanya masih buah
Perbedaan utama di sini adalah bahwa GraphQL adalah bahasa yang digerakkan oleh klien. Ini memiliki arsitektur di mana aplikasi front-end memutuskan data apa yang akan diambil dan berapa banyak yang harus dikembalikan dari server. Pada REST, semuanya dirancang di server, sehingga server menggerakkan arsitektur.
| GrafikQL | REST |
| Bahasa kueri yang menawarkan efisiensi dan fleksibilitas untuk memecahkan masalah umum saat mengintegrasikan API | Gaya arsitektur sebagian besar dipandang sebagai standar konvensional untuk merancang API |
| Di-deploy melalui HTTP menggunakan satu titik akhir yang menyediakan kemampuan penuh dari layanan yang terbuka | Di-deploy ke sekumpulan URL di mana masing-masing URL memperlihatkan satu sumber daya |
| Menggunakan arsitektur yang digerakkan oleh klien | Pengguna arsitektur berbasis server |
| Tidak memiliki mekanisme caching otomatis | Menggunakan caching secara otomatis |
| NO API versioning | Mendukung beberapa versi API |
| Hanya representasi JSON | Mendukung berbagai format data |
| Hanya satu alat yang digunakan terutama untuk dokumentasi: GraphiQL | Berbagai pilihan untuk dokumentasi otomatis, seperti OpenAPI dan API Blueprint |
| Mempersulit penanganan kode status HTTP untuk mengidentifikasi kesalahan | Menggunakan kode status HTTP untuk mengidentifikasi kesalahan dengan mudah |
Alasan Menggunakan GraphQL
Ada tiga alasan utama mengapa kami mungkin ingin mempertimbangkan untuk menggunakan GraphQL daripada REST.
- Kinerja Jaringan. Jika kita ingin meningkatkan kinerja jaringan dengan mengirimkan lebih sedikit data atau hanya mengirimkan informasi yang kita butuhkan untuk klien.
- Pilihan Desain “Sertakan vs Titik Akhir”. Ada pilihan rumit antara menyertakan permintaan atau membuat titik akhir tambahan. Dengan GraphQL masalah itu terpecahkan karena fungsi skema dan resolver . Jadi klien memiliki kendali atas data apa yang harus dikembalikan.
- Mengelola berbagai jenis klien. Bayangkan Anda memiliki satu API, dan semua klien (aplikasi iOS, aplikasi Android, aplikasi web, dll.) benar-benar berbeda satu sama lain: mereka membutuhkan struktur atau jumlah data yang sama sekali berbeda yang dikembalikan dari server. Dengan pendekatan REST, Anda dapat membuat API terpisah. Sebaliknya, dengan GraphQL, Anda tidak perlu melakukannya karena Anda dapat mengembalikan semuanya dari satu titik akhir.
Bagaimana Memulainya?
Ini adalah rincian bagaimana kueri dibangun. Tiga bagian utama dipertimbangkan: 1) jenis operasi, 2) titik akhir operasi, 3) bidang yang diminta.
Syarat untuk Dipelajari
Tidak peduli implementasi apa yang akan dipilih karena ada banyak bahasa, itu tidak hanya tersedia di JavaScript atau Node – Anda dapat menggunakan PHP, Python, JAVA, Go, dan lainnya. Setiap bahasa memiliki implementasi GraphQL sendiri, jadi Anda tidak perlu membangun semuanya dari awal. Ada alat dan paket yang dapat Anda gunakan, dan istilah-istilah itu hampir sama pada semuanya, jadi mungkin ada baiknya mempelajarinya jika Anda ingin membangun API menggunakan GraphQL:
Jenis. Model data di GraphQL diwakili dalam tipe, yang sangat diketik. Harus ada pemetaan 1-ke-1 antara model Anda dan kode GraphQL. Anda dapat menganggap ini sebagai tabel database di mana tabel pengguna memiliki bidang seperti id, nama depan, nama belakang, email, proyek. Jadi, hal yang perlu diingat adalah tanda seru yang mengatakan bahwa pengenal (id) tidak dapat dibatalkan atau, dengan kata lain, harus ada sesuatu di sana karena itu adalah bidang wajib.
Pertanyaan. Kueri menentukan kueri apa yang dapat Anda jalankan di GraphQL API Anda. Dengan konvensi, harus ada RootQuery, yang berisi semua kueri yang ada. Dalam contoh, komentar di sini menunjukkan tampilannya di API lainnya. Dalam tanda kurung di sekitar tanda kurung, kita melihat argumen yang harus berupa pengenal unik, dan setelah titik dua adalah tipe pengguna. Ini menunjukkan apa yang harus dikembalikan ketika kami melakukan kueri ini, jadi itu mengembalikan pengguna. Kueri proyek akan mengembalikan proyek, kueri tugas akan mengubah daftar tugas, dan seterusnya.
Mutasi. Jika kueri adalah permintaan GET, mutasi dapat dilihat sebagai POST | PATCH | PUT | DELETE permintaan yang mengubah data. Contohnya termasuk mutasi “createUser”, “updateUser”, “removerUser”.
Memasukkan. Tipe UserInput adalah tipe Pengguna tanpa bidang id dan proyek. Perhatikan kata kunci input alih-alih type . Anda dapat menganggap ini sebagai formulir di halaman di mana Anda perlu memasukkan beberapa data dan jenis informasi apa yang perlu dimasukkan untuk membuat profil pengguna itu.
Resolver. Fungsi resolver memberikan serangkaian instruksi khusus untuk mengubah operasi GraphQL menjadi data. Ini pada dasarnya adalah fungsi pengontrol, logika apa yang harus dikembalikan (penyelesai untuk kueri) ketika kueri itu terjadi dan pengguna meminta data, dan penyelesai untuk mutasi digunakan ketika pengguna berusaha memperbarui atau menghapus data.
Skema. Dengan tipe, kueri, dan mutasi, kami mendefinisikan skema GraphQL, yang ditunjukkan oleh titik akhir GraphQL kepada dunia.
Sumber daya untuk diperiksa
Dua sumber daya utama untuk melangkah lebih dalam ke bidang GraphQL:
- GraphQL.org . Didedikasikan untuk mempelajari semua dasar-dasar dan spesifikasi sebenarnya dari GraphQL.
- Bagaimana GraphQL? Didedikasikan untuk belajar tentang implementasi. Misalnya, jika Anda ingin mengetahui tentang server Apollo, ini memberi Anda pemahaman tentang kerangka kerja front-end apa yang dapat digunakan untuk menggunakan data dari API itu. Tidak perlu menggunakan alat atau pustaka apa pun untuk front-end untuk menggunakan API – Anda dapat melakukan permintaan XmlHttp biasa, tetapi Anda harus membuat permintaan POST ke titik akhir itu dan menyediakan kueri di badan, yaitu GraphQL.
API server GraphQL dapat digunakan sebagai pintu gerbang ke layanan mikro lainnya, berbicara langsung ke database atau API REST lainnya. Dengan demikian, Anda dapat memiliki beberapa REST API, mendapatkan data itu, dan menjadikannya satu sumber kebenaran.
Artikel ini terinspirasi oleh presentasi front-end developer Gediminas Survila tentang “GraphQL vs. REST: Mana yang terbaik untuk Pengembangan API?”