GraphQL Agak Menyebalkan

• GraphQL memang hebat, tetapi rasanya agak dibesar-besarkan
• Developer pemula hingga menengah tampaknya jadi memakai GraphQL setelah menonton YouTube, tetapi ini terasa keliru
• Kelebihan
  • Bisa menjelaskan data yang diinginkan dengan mudah
  • Menghemat bandwidth. Bisa mengambil sebanyak yang diinginkan sekaligus
  • Mudah membuat dokumentasi untuk konsumen data
  • Lebih mudah menggunakan subscription
  • Bisa menggabungkan beberapa pemanggilan API
• Kekurangan
  • Dalam praktiknya menyakitkan untuk digunakan. Bergantung pada backend yang dipakai, jika tidak dibuatkan kode dalam bahasa Anda maka Anda harus mengelola 2 atau lebih sistem tipe
  • Tidak mendukung map/table/dictionary. Ini masalah besar. Walau tidak mau, pada akhirnya Anda akan memakai sesuatu seperti {[key: string] : T} di suatu tempat
  • Tidak ada cara yang jelas untuk versioning API. Pada akhirnya Anda akan membuat hal seperti MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
• Jika Anda tidak sedang menangani kumpulan solusi/masalah yang Facebook maksudkan untuk GraphQL, jangan gunakan GraphQL
• Adakah nasihat bijak dari para developer senior lain untuk menyelamatkan developer baru agar tidak terjebak ke rawa ini?

Komentar di HN

• Masalah terbesar GraphQL adalah Anda harus bekerja untuk mempertahankan diri dari serangan DOS, atau dari orang-orang yang mencoba mengunduh seluruh DB Anda.
  • Sangat mudah membuat kueri yang memberi beban berlebihan pada sistem Anda.
  • Jika ingin melihat hal-hal yang perlu dilakukan, lihat Shopify. Mereka menerapkan rate limit berdasarkan jumlah data yang dikembalikan, serta menangani cursor dan pagination. Tidak seperti contoh GraphQL yang cantik di internet, skemanya besar dan jelek
• GraphQL adalah cara yang sangat baik untuk menyelesaikan masalah organisasi yang dimiliki perusahaan teknologi besar
  • Misalnya ketika tim yang memelihara API berbeda dengan tim yang meminta perubahan
  • Jika organisasinya besar, menunggu perubahan bisa makan waktu sangat lama, jadi GraphQL mengurangi kebutuhan itu
  • Jika organisasinya kecil, bukankah lebih baik langsung membuat dan menambahkan bagian yang kurang sendiri?
• Disengaja atau tidak, GraphQL memungkinkan developer frontend terlepas dari ketergantungan pada permintaan kepada developer backend sehingga bisa bergerak lebih cepat
  • Jika developer backend membuat model data lalu mengeksposnya lewat GraphQL, developer frontend yang bahkan belum pernah bertemu developer backend tersebut pun bisa langsung memakainya
  • Bisa mengubah isi kueri secara spontan dan mengambil apa yang diinginkan
  • Membuat semua orang bergerak lebih cepat
  • Tetapi sebagai developer backend, saya benar-benar benci GraphQL

[bichi]

GraphQL itu memang agak menyebalkan. Bukan sampai sangat menyebalkan, cuma agak bikin kesal, tapi karena jelas mengurangi biaya komunikasi antaranggota tim, lebih efisien menyelesaikan bagian yang menyebalkan itu di waktu tersebut. Dan tampilannya benar-benar jelek. Tapi saya tetap merekomendasikan memakai GraphQL. Toh tidak ada yang bakal setuju kalau diajak pakai tRPC. Kebanyakan orang bahkan belum pernah benar-benar mencobanya, tapi sudah menolak penggunaan teknologi hanya berdasarkan asumsi. Untuk mengatasinya, sebenarnya harus didorong dengan wewenang yang kuat, tapi mungkin itu bisa dilakukan untuk 1~2 teknologi saja; kalau semua dipaksakan, yang hilang justru lebih banyak, jadi tidak bisa. ... Jadi pada akhirnya, tingkat yang paling mungkin untuk dibujuk adalah GraphQL T_T REST sialan ini, teknologi batu tua yang benar-benar buruk karena biaya komunikasinya sangat besar T_T

[alucard]

Ini pertama kalinya saya sampai daftar akun setelah membaca GeekNews. Saya sudah membalas di bagian The bad.

Mungkin ada kelebihan dan kekurangan dari sudut pandang klien/server masing-masing, tetapi jika dilihat secara keseluruhan, meskipun kita paham bahwa value proposition terbesar GraphQL adalah schema GraphQL mengisi lapisan abstraksi yang hilang antara server dan klien, menurut saya mengatakan bahwa untuk produk umum masih akan mempertimbangkan REST terasa seperti cerita yang agak lama.
The bad

• It is actually a pain to use, depending on the backend you are using you'll have to manage
  two or more type systems if there are no code first generates in your language
  Jadi pada akhirnya kalau diungkapkan dengan cara lain: kalau dipakai dengan benar, bagus, ya? code generation dan semacamnya juga bukan masalah zaman sekarang. Tooling sudah berkembang sejauh itu.
• It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
  some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
  Ini juga disebutkan di Production Ready, tetapi kalau memanfaatkan kelebihan Type System, rasanya ini bukan hal yang perlu terlalu dipikirkan. Tinggal tentukan field yang tepat, bukan key: string..
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  GraphQL pada dasarnya memang versionless....
  Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
  Kedengarannya seperti mengatakan React juga jangan dipakai kalau bukan untuk menyelesaikan masalah yang ingin dipecahkan Facebook.

[bichi]

Halo, pendapat yang bagus. Mungkinkah kita saling mengenal? Saya butuh orang-orang yang berpikiran sama. Terlalu sulit meyakinkan orang lain (anggota tim).

[alucard]

Haha, saya telat melihat komentarnya..!! Saya menggunakan nama panggilan Alucard di Slack GraphQL Korea :)

[sixmen]

Saya mengadopsi GraphQL relatif sejak awal, dan saat itu banyak penjelasan yang berfokus pada backend. Karena itu, saya rasa ada persepsi bahwa ini akan terasa bagus dari sisi backend.

Setelah saya mencoba ini-itu dan cukup banyak jungkir balik, ketika orang-orang yang bergabung ke perusahaan setelah saya atau para kandidat saat wawancara bertanya, saya biasanya menjelaskannya seperti ini: berat untuk backend, tapi bagus untuk frontend. :)

[bbulbum]

#Tapi sebagai pengembang backend, saya benar-benar tidak suka GraphQL
Setuju..

[ifmkl]

Ungkapan “sesuai tempat dan kebutuhannya” langsung terlintas di benak saya.

[kbumsik]

Entah ini memang disengaja atau tidak, GraphQL membuat developer frontend bisa bergerak lebih cepat karena terlepas dari tuntutan terhadap developer backend

Itulah alasan memakai GraphQL. Bahkan di spesifikasi GraphQL juga disebutkan bahwa ini ditujukan untuk frontend 1
Saya juga mulai memakai GraphQL di startup baru, dan rasanya frekuensi saya harus berkomunikasi dengan engineer frontend soal API memang jelas berkurang dibanding sebelumnya.

Dari sudut pandang engineer backend, memang ada masalah-masalah yang tidak terpikirkan sebelum benar-benar memakai GraphQL dan itu agak menyakitkan, tetapi rasanya tetap jauh lebih baik daripada pusing memikirkan cara mendesain REST API dengan baik.

[hwasurr]

Tidak ada teknologi yang sempurna! Saya rasa, jika teknologi tersebut memang dibutuhkan sampai biaya untuk mengatasi kekurangannya layak ditanggung, atau jika ia menyelesaikan masalah lain yang lebih besar, maka teknologi itu patut dipertimbangkan untuk diadopsi. Kecocokan suatu teknologi/alat pada akhirnya selalu ditentukan oleh situasi penggunanya.

Di sisi lain, salah satu alasan GraphQL mendapat serangan mungkin karena ia menonjolkan(?) citra sebagai sesuatu yang 'mudah'.

[jjpark78]

Di awal saat GraphQL muncul dan kami menjalankan proyek POC, tidak ada engine yang mendukung multipart dengan baik, jadi saya ingat waktu itu cukup berat..

[gjen6s]

Saya juga sejak dulu sering berpikir, saat melihat penggunaan GraphQL di proyek kecil, bukankah ini terlalu berlebihan... ternyata banyak orang juga berpikir sama.

[xguru]

Saya hanya memindahkan komentar-komentar awal. Ada lebih dari 400 komentar, jadi sulit juga untuk membaca semuanya.