- GraphQL berusaha menyelesaikan masalah permintaan data berlebih, tetapi di sebagian besar lingkungan enterprise, masalah ini sebenarnya sudah diselesaikan dengan cara lain
- Dalam sistem perusahaan yang sudah umum memakai arsitektur BFF(Backend for Frontend), keunggulan utama GraphQL jadi jauh berkurang
- Kompleksitas implementasi, observabilitas yang menurun, masalah caching, batasan ID, serta repotnya penanganan file membuat biayanya membesar di lingkungan produksi nyata
- REST lebih sederhana dan cepat, serta lebih mudah untuk penanganan error dan onboarding, sehingga lebih efisien untuk lingkungan tim skala besar
- Kesimpulannya, GraphQL berguna dalam situasi tertentu, tetapi bagi kebanyakan enterprise merupakan pilihan yang berlebihan
Masalah yang Ingin Diselesaikan GraphQL
- Tujuan utama GraphQL adalah mencegah overfetching (permintaan data berlebih yang tidak diperlukan)
- Klien dapat meminta hanya field yang dibutuhkan sehingga mengurangi pengiriman data yang tidak perlu
- Ada keuntungan karena backend tidak perlu diubah setiap kali muncul kebutuhan UI baru
- Namun di lingkungan nyata, struktur ideal ini tidak cocok dengan realitas yang kompleks
Overfetching Sudah Diselesaikan dengan BFF
- Sebagian besar frontend enterprise menggunakan lapisan BFF(Backend for Frontend)
- Lapisan ini menggabungkan data sesuai kebutuhan UI, menyatukan beberapa panggilan downstream, dan menyembunyikan kompleksitas backend
- BFF berbasis REST sudah bisa mengembalikan hanya data yang diperlukan, sehingga keunggulan GraphQL menjadi tumpang tindih
- Jika lapisan GraphQL mengambil data dari REST API, overfetching hanya berpindah satu lapisan ke bawah
- GraphQL bisa berguna ketika beberapa halaman berbagi endpoint yang sama, tetapi
- manfaat itu pada akhirnya hanya setara dengan menukar beberapa kilobyte penghematan dengan beban setup dan pemeliharaan yang lebih besar
Kompleksitas Implementasi dan Turunnya Produktivitas
- GraphQL membutuhkan waktu implementasi yang jauh lebih lama dan lebih kompleks dibanding REST
- Perlu pekerjaan tambahan seperti mendefinisikan schema, type, resolver, dan data source
- Ada juga beban untuk menjaga sinkronisasi antara schema dan klien
- GraphQL mengoptimalkan konsumsi (kenyamanan klien), tetapi mengorbankan produksi (kecepatan pengembangan server)
- Di lingkungan enterprise, kecepatan produksi dan kesederhanaan lebih penting
Masalah Observabilitas dan Monitoring
- Sistem HTTP status code pada GraphQL tidak konsisten
- Respons 200 pun bisa memuat error, sehingga sulit membedakan sukses/gagal saat monitoring
- Pada REST, 2XX/4XX/5XX dipisahkan dengan jelas sehingga filtering dashboard lebih intuitif
- Memang bisa dikustomisasi di Apollo dan sejenisnya, tetapi itu menimbulkan setup tambahan dan beban mental
- Saat menangani insiden di produksi, identifikasi masalah lebih sulit dan lebih kompleks dibanding REST
Batasan Praktis Caching
- Normalized caching milik Apollo secara teori kuat, tetapi dalam praktiknya rapuh dan kompleks
- Query yang hanya berbeda satu field pun diperlakukan terpisah sehingga perlu pengaitan manual
- Debugging cache berkembang menjadi masalah tersendiri
- Sebaliknya, REST cukup melakukan caching pada seluruh respons sehingga lebih stabil dan mudah dipelihara
Masalah Batasan Field ID
- Apollo mengasumsikan semua objek memiliki field id atau _id
- Banyak API enterprise tidak memiliki ID unik, atau ID tersebut bukan identifier global
- Agar sesuai, BFF harus menambahkan logika pembuatan ID lokal
- Akibatnya, field dan logika yang tidak perlu bertambah, sehingga efek pengurangan overfetching ikut tereduksi
Inefisiensi Upload dan Download File
- GraphQL tidak cocok untuk menangani data biner
- Dalam praktiknya, sistem akan mengembalikan URL download, lalu file tetap dikirim lewat REST
- Jika data besar seperti PDF dimasukkan ke respons GraphQL, kinerja akan menurun
- Karena itu, ideal GraphQL sebagai “single API” pun runtuh
Onboarding dan Learning Curve
- Sebagian besar developer sudah berpengalaman dengan REST, tetapi GraphQL perlu dipelajari
- Perlu mempelajari konsep baru seperti schema, resolver, susunan query, aturan caching, dan penanganan error
- Ini menyebabkan kecepatan onboarding tim menurun
- REST adalah pendekatan yang “membosankan tetapi sangat skalabel” sehingga cocok untuk tim besar
Kompleksitas Penanganan Error
- Respons error GraphQL itu rumit, dengan nullable field, partial data, array errors, dan extended status code
- Perlu melacak resolver mana yang gagal
- REST cukup dibedakan dengan 400/500 sehingga lebih mudah dipahami dan di-debug
Kesimpulan: GraphQL adalah Teknologi Niche
- GraphQL adalah alat yang valid dalam situasi tertentu
- Namun di sebagian besar lingkungan enterprise, masalahnya sudah diselesaikan dengan BFF dan REST
- Tantangan utama bukan overfetching, melainkan observabilitas, keandalan, dan kecepatan
- Pada akhirnya, GraphQL menyelesaikan masalah yang sempit sambil menciptakan kompleksitas yang lebih luas
- Kesimpulannya adalah, “GraphQL tidak buruk, tetapi dalam kebanyakan kasus memang tidak diperlukan”
Belum ada komentar.