Kasus penggunaan untuk beberapa endpoint kustom
GraphQL diharapkan mengekspos satu endpoint untuk melakukan query data. Namun, ada situasi di mana lebih masuk akal untuk mengekspos beberapa endpoint kustom, di mana setiap endpoint ini menyajikan skema yang dikustomisasi. Hal ini memungkinkan kita memberikan perilaku berbeda untuk pengguna atau aplikasi yang berbeda hanya dengan mengganti endpoint yang diakses.
Mengekspos beberapa endpoint di GraphQL tidak sama dengan REST. Sementara di REST setiap endpoint menyediakan akses ke sumber daya atau sekumpulan sumber daya yang telah ditentukan, setiap endpoint GraphQL yang berjumlah banyak tetap akan menyediakan akses ke seluruh data dari skemanya, memungkinkan kita mengambil tepat apa yang kita butuhkan. Jadi ini tetap merupakan perilaku GraphQL yang normal, dengan tambahan kemampuan untuk mengakses data dari skema yang berbeda.
Kemampuan ini juga berbeda dari schema stitching atau federation, yang memungkinkan penggabungan beberapa sumber data ke dalam satu graf terpadu. Dengan beberapa endpoint kita berhadapan dengan beberapa skema. Tujuannya adalah menangani skema-skema tersebut secara mandiri, dan bukan sebagai bagian dari skema yang lebih besar.
Mengekspos skema yang berbeda dapat memberikan akses ke beberapa graf independen. Pencipta GraphQL, Lee Byron, menjelaskan kapan hal ini bisa berguna:
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
Mari kita jelajahi beberapa kasus penggunaan tambahan di mana mengekspos beberapa endpoint GraphQL masuk akal.
Mengekspos endpoint admin dan publik secara terpisah
Ketika kita menggunakan satu graf untuk semua data di perusahaan, kita dapat memvalidasi siapa yang memiliki akses ke berbagai field dalam skema GraphQL kita dengan menyiapkan kebijakan kontrol akses. Misalnya, kita dapat mengonfigurasi field agar hanya dapat diakses oleh pengguna yang sudah login atau pengguna dengan peran tertentu.
Namun, ketika ada field yang berisi informasi sensitif atau rahasia, sehingga dalam keadaan apapun field tersebut tidak boleh dapat diakses oleh pihak yang tidak berwenang, maka sebaiknya kita tidak mengekspos field tersebut di skema publik sejak awal, dan hanya di skema privat yang hanya dapat diakses oleh tim. Strategi ini akan melindungi data privat kita dari masalah yang tidak disengaja, seperti bug perangkat lunak dan kelalaian saat mengonfigurasi skema, bahkan memperketat keamanan dengan hanya mengizinkan pengunjung dari IP tertentu untuk mengakses endpoint privat.
Oleh karena itu, kita dapat membuat dua skema terpisah, yaitu skema Admin dan Publik, dan mengeksposnya di bawah endpoint /graphql/admin (dan membatasi aksesnya hanya untuk pengunjung dari IP tertentu) dan /graphql/public (dapat diakses oleh semua orang) masing-masing.
Membatasi akses ke informasi privat dengan cara yang lebih aman
Bagian ini merupakan generalisasi dari bagian sebelumnya: bukan hanya soal publik vs admin, tetapi setiap situasi di mana sekumpulan pengguna pasti tidak boleh dapat mengakses informasi dari sekumpulan pengguna lain.
Misalnya, setiap kali kita perlu membuat skema yang dikustomisasi untuk klien-klien yang berbeda, kita dapat mengekspos endpoint kustom untuk masing-masing dari mereka (/graphql/some-client, /graphql/another-client, dsb), yang bisa lebih aman daripada memberi mereka akses ke skema terpadu yang sama dan memvalidasinya melalui kontrol akses.
Memberikan perilaku berbeda kepada aplikasi yang berbeda
Kita dapat memberikan perilaku yang berbeda kepada aplikasi-aplikasi berbeda yang mengakses sumber data yang sama.
Misalnya, Reddit menghasilkan respons yang berbeda jika diakses dari browser desktop atau dari browser mobile. Dari browser desktop, baik kita sudah login maupun belum, kita dapat langsung melihat kontennya:
Namun saat mengakses dari mobile, kita harus sudah login untuk mengakses konten, dan kita dianjurkan untuk menggunakan aplikasinya:
Perilaku yang berbeda ini dapat disediakan dengan membuat dua skema, yaitu skema Desktop dan Mobile, dan mengeksposnya di bawah /graphql/desktop dan /graphql/mobile masing-masing.
Menghasilkan situs dalam berbagai bahasa
Jika kita ingin menghasilkan situs yang sama dalam berbagai bahasa, kita dapat menjadikan kode bahasa sebagai bagian dari struktur endpoint kustom, seperti /graphql/en untuk bahasa Inggris dan /graphql/fr untuk bahasa Prancis. Kemudian, server GraphQL dapat mengambil informasi ini dan menerjemahkan data ke bahasa yang diinginkan.
Akhirnya, kita mengarahkan ke masing-masing endpoint ini di static site generator untuk menghasilkan situs dalam satu bahasa atau bahasa lainnya:
Menguji skema yang diperbarui sebelum dirilis ke produksi
Jika kita ingin memperbarui skema GraphQL kita, dan memiliki sekumpulan pengguna untuk mengujinya terlebih dahulu, kita dapat mengekspos skema baru ini melalui endpoint /graphql/upcoming. Bahkan lebih jauh, kita juga bisa mengekspos endpoint /graphql/bleeding-edge, yang terus men-deploy skema dari DEV.
Mendukung pendekatan BfF
Backend-for-Frontends (disingkat BfF) adalah sebuah pendekatan untuk menghasilkan API yang berbeda untuk klien yang berbeda, di mana setiap klien "memiliki" API-nya sendiri, memungkinkannya menghasilkan versi yang paling optimal berdasarkan kebutuhannya sendiri.
Dalam model ini, BfF kustom adalah perantara antara layanan back-end dan kliennya:
Model ini dapat dipenuhi di GraphQL dengan membuat semua BfF diimplementasikan dalam satu server GraphQL dengan beberapa endpoint, di mana setiap endpoint menangani BfF/klien tertentu (seperti /graphql/mobile dan /graphql/web):
