Petunjuk dan konteks
Anda mengelola B2B SaaS dengan REST API yang sudah mapan. Pelanggan skala besar menginginkan GraphQL untuk menyusun kueri lintas sumber daya, sementara tim rekayasa mengkhawatirkan biaya kueri, batas otorisasi, caching, dan tata kelola jangka panjang. Tentukan apakah akan meluncurkan GraphQL dan jelaskan cakupan, metrik, risiko, serta rencana migrasinya.
Ini adalah keputusan produk API, bukan undangan untuk mengimplementasikan server GraphQL. Spesifikasi GraphQL menjelaskan bahasa kueri dan mesin eksekusi untuk kemampuan serta persyaratan model data; API publik GitHub mendukung kueri dan mutasi. Tugas Anda adalah mengubah kemampuan tersebut menjadi pilihan produk yang dapat diuji.
Hal yang diuji oleh pewawancara
- Memulai dari alur kerja pelanggan dan kendala yang terukur alih-alih memilih GraphQL hanya karena sedang populer.
- Membandingkan REST, GraphQL, dan lapisan agregasi pada aspek penemuan (discovery), round trip, otorisasi, caching, dan observabilitas.
- Mengubah skema, kompleksitas kueri, paginasi, dan batasan mutasi menjadi batasan produk.
- Merancang uji coba bertahap, rencana kompatibilitas, pendekatan penetapan harga, dan metrik pengalaman pengembang (developer experience).
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah kendalanya adalah pengurangan round trip, pengurangan over-fetching, atau komposisi lintas sumber daya? Bisakah agregasi REST yang ada menyelesaikannya?
- Berapa banyak konsumen, tumpukan bahasa (language stacks), wilayah kepatuhan, dan target SLO yang masuk dalam cakupan? Apakah mitra bergantung pada kontrak yang stabil?
- Apakah kueri hanya-baca (read-only) sudah cukup, atau diperlukan penulisan (writes)? Apakah penulisan memerlukan transaksi, idempotensi, dan persetujuan?
- Sumber daya dan bidang mana yang menentukan batasan penyewa (tenant boundary)? Bagaimana kedalaman, ukuran respons, dan anggaran per penyewa akan dibatasi?
Jawaban 30 detik
Saya akan memvalidasi masalah komposisi berulang dengan pelanggan dan menguji coba serangkaian sumber daya kecil yang bersifat hanya-baca. Jika agregasi REST sudah menyelesaikan alur kerja bernilai tinggi dengan biaya murah, saya tidak akan meluncurkan GraphQL hanya demi protokolnya. Jika beberapa pelanggan memerlukan kombinasi bidang yang berbeda dan memelihara endpoint kustom membutuhkan biaya tinggi, saya akan meluncurkan produk GraphQL yang dibatasi. Rilis pertama akan mengekspos skema kueri yang stabil, paginasi, dan anggaran kompleksitas, menggunakan kembali identitas dan otorisasi penyewa yang ada, serta menunda mutasi arbitrer. Saya akan meningkatkan skala atau menghentikannya berdasarkan aktivasi, tingkat keberhasilan, latensi P95, biaya kueri, beban dukungan, dan migrasi REST.
Pembahasan mendalam langkah demi langkah
Tentukan nilai pelanggan dan alternatifnya terlebih dahulu
Bagi permintaan menjadi: pengurangan round trip jaringan, pengurangan over-fetching, dan komposisi lintas sumber daya. Untuk masing-masing hal tersebut, catat grafik panggilan REST saat ini, latensi ujung-ke-ujung (end-to-end), jumlah endpoint kustom, dan biaya proksi yang dibangun pelanggan. Jika satu endpoint agregasi REST menyelesaikan sebagian besar alur kerja yang bernilai, sertakan biaya tata kelola GraphQL dalam perbandingan daripada hanya menghitung jumlah permintaan.
Tetapkan batasan produk daripada mengekspos basis data
Skema pertama harus mencakup sumber daya dengan semantik yang stabil, kepemilikan penyewa yang jelas, dan perilaku yang dapat diobservasi. Beri tag pada setiap bidang dengan tingkat sensitivitas, aturan otorisasi, jaminan versi, dan kesegaran data (freshness). Tinjau kueri dan mutasi secara terpisah: validasi nilai baca terlebih dahulu, lalu pertimbangkan operasi tulis setelah idempotensi, audit, dan semantik kesalahan matang.
Jadikan biaya kueri sebagai anggaran yang dapat ditegakkan
Kumpulan seleksi fleksibel pada GraphQL menggeser biaya dari jumlah endpoint ke bentuk kueri. Batasi kedalaman maksimum, jumlah node, ukuran halaman, dan waktu tunggu (timeout), serta perkirakan biaya berdasarkan bidang skema atau resolver. Tolak permintaan yang melebihi anggaran dengan pesan kesalahan yang dapat ditindaklanjuti sambil mencatat penyewa, nama operasi, perkiraan biaya, dan penggunaan sumber daya aktual.
Pertahankan batas identitas, otorisasi, dan penyewa
GraphQL mengubah bentuk permintaan; ini tidak boleh melewati OAuth, akun layanan, isolasi penyewa, atau izin tingkat bidang yang ada. Terapkan otorisasi pada resolver atau lapisan akses data bersama, bukan hanya pada kueri akar. Pembacaan batch harus mencegah penggabungan lintas penyewa (cross-tenant joins), penggunaan kembali cache tanpa izin, dan kebocoran informasi melalui pesan kesalahan.
Rencanakan pengalaman pengembang dan kompatibilitas
Sediakan dokumentasi skema, contoh kueri, panduan kesalahan, konvensi paginasi, persyaratan nama operasi, dan log perubahan (changelog). Perubahan skema yang merusak (breaking changes) memerlukan jendela penghentian bertahap (deprecation window), pemindaian pemanggil, dan kontak yang ditunjuk. REST dan GraphQL dapat berbagi model domain, tetapi jangan menjanjikan paritas bidang satu-ke-satu selamanya.
Tentukan uji coba, metrik, dan kriteria keluar
Pilih 2 hingga 3 pelanggan representatif dan alur kerja hanya-baca dengan sumber daya dan anggaran tetap. Lacak aplikasi aktif, tingkat kueri valid, latensi P95/P99, biaya per kueri, upaya otorisasi yang diblokir, tiket dukungan, dan waktu untuk menyelesaikan tugas pelanggan. Adopsi yang rendah, biaya tinggi, atau insiden tata kelola yang meningkat harus menjadi alasan untuk memperkecil skema atau menghentikan ekspansi alih-alih ditutupi dengan menambahkan bidang baru.
{
"pilot": {"tenants": 3, "mode": "read-only", "maxDepth": 6, "costBudget": 100},
"exit": {"p95LatencyMs": 400, "errorRate": 0.01, "supportTicketsPerTenant": 2}
}Contoh jawaban yang kuat
Saya tidak akan memperlakukan GraphQL sebagai pengganti REST yang tak terelakkan. Saya akan menggunakan bukti pelanggan untuk memastikan bahwa komposisi, over-fetching, atau pemeliharaan endpoint kustom cukup membebani, dan membandingkannya dengan biaya pengiriman lapisan agregasi REST. Jika uji coba membuktikan nilainya, saya akan menjadikan GraphQL sebagai produk API yang diatur dengan baik: skema hanya-baca yang stabil, OAuth dan otorisasi penyewa yang ada, kewajiban menyertakan nama operasi, batas kedalaman, node, paginasi, dan biaya, ditambah dokumentasi skema serta jendela penghentian bertahap. Google Apigee memodelkan produk API sebagai bundel sumber daya, metode, tingkat akses, dan kuota, yang menjadi pengingat berguna untuk merancang kontrol akses, batasan, dan paket GraphQL secara bersamaan. Saya akan menggunakan metrik pelanggan aktif, tingkat keberhasilan, P95, biaya kueri per unit, dan beban dukungan untuk memutuskan apakah akan melakukan ekspansi; baru setelah itu saya menambahkan sumber daya dan mutasi dengan cakupan terbatas.
Kesalahan umum
- Mengatakan "frontend menjadi lebih fleksibel" tanpa membuktikan nilai pelanggan atau membandingkannya dengan agregasi REST.
- Memetakan skema GraphQL langsung ke tabel basis data dan mengabaikan semantik domain, otorisasi, serta bidang sensitif.
- Mengizinkan kedalaman, paginasi, atau penumpukan (nesting) tanpa batas tanpa model biaya dan strategi penolakan.
- Meluncurkan kueri dan mutasi secara bersamaan tanpa batasan idempotensi, audit, persetujuan, atau rollback.
- Hanya melacak adopsi sambil mengabaikan latensi, biaya, otorisasi yang diblokir, dan beban dukungan.
- Menjanjikan migrasi satu kali untuk setiap pelanggan REST sambil mengabaikan dokumentasi jalur ganda, penghentian bertahap, dan rollback.
Pertanyaan lanjutan dan tanggapan
Jika pelanggan hanya menginginkan lebih sedikit permintaan, mengapa tidak membangun agregasi REST?
Kuantifikasi kedua opsi dengan grafik panggilan dan biaya pemeliharaan. Alur kerja tetap dan sering dilakukan dengan batasan yang jelas lebih cocok menggunakan endpoint agregasi; kombinasi yang terus berubah di banyak pelanggan membuat GraphQL terbatas menjadi lebih bernilai. Uji coba alur kerja yang sama sebelum memilih permukaan protokol.
Bagaimana Anda mencegah kueri GraphQL melumpuhkan backend?
Terapkan batas kedalaman, node, paginasi, dan batas waktu di edge; pertahankan bobot biaya bidang dalam skema; lakukan batching dan caching di resolver; dan terapkan pembatasan laju (rate limit) berdasarkan penyewa dan prioritas. Catat nama operasi, perkiraan biaya, dan penggunaan sumber daya untuk kueri yang ditolak alih-alih mengembalikan kesalahan server yang tidak jelas.
Kapan Anda akan mengekspos mutasi?
Hanya setelah otorisasi hanya-baca, penanganan kesalahan, audit, dan observabilitas stabil. Mulailah dengan penulisan berisiko rendah, idempoten, dan dapat dikompensasi. Setiap mutasi memerlukan validasi input, semantik konflik, izin, peristiwa audit, dan perilaku coba lagi (retry); tindakan finansial, penghapusan, dan lintas penyewa harus tetap menjadi alur kerja khusus.
Bagaimana REST dan GraphQL akan hidup berdampingan?
Pertahankan REST sebagai permukaan kompatibilitas yang stabil dan gunakan GraphQL untuk alur kerja baru tanpa memerlukan paritas bidang demi bidang secara mutlak. Bagikan identitas, otorisasi domain, audit, dan SLO, sambil mengukur migrasi pemanggil dan biaya setiap permukaan secara terpisah. Diskusikan penghentian REST hanya ketika nilai pelanggan, biaya operasional, dan risiko kompatibilitas didukung oleh bukti nyata.