Alasan Saya Berhenti Menggunakan GraphQL Setelah 6 Tahun

• Setelah menggunakannya selama 6 tahun sejak 2018, saya adalah penggemar berat GraphQL sejati, tetapi sekarang mulai ragu
• Saya ingin menjelaskan mengapa saya tidak lagi merekomendasikan GraphQL dan apa yang menurut saya merupakan alternatif yang lebih baik

Permukaan serangan

• GraphQL memiliki risiko memperluas permukaan serangan karena mengekspos bahasa kueri.
• Masalah yang terkait dengan otorisasi sangat penting.
  • Pemeriksaan otorisasi yang tepat diperlukan untuk setiap field.
  • Di REST API, lebih sederhana untuk memeriksa otorisasi per endpoint.

Otorisasi

• Hak akses pengguna harus diperiksa untuk setiap field.
• Di REST API, lebih sederhana untuk memeriksa otorisasi per endpoint.

Pembatasan laju

• Kueri GraphQL tidak memiliki batas ukuran, sehingga dapat memberi beban besar pada server.
• Ada cara untuk memperkirakan kompleksitas kueri dan membatasi kueri yang melebihi kompleksitas tertentu.
• Di REST API, lebih sederhana untuk membatasi jumlah permintaan.

Parsing kueri

• String kueri yang salah dapat menggunakan memori server secara berlebihan.
• Ada cara untuk menghentikan parsing dengan menetapkan jumlah kesalahan maksimum.

Kinerja

Pengambilan data dan masalah N+1

• Resolver field dapat memanggil sumber data eksternal berkali-kali.
• Masalah ini dapat diatasi dengan menggunakan pola Dataloader.
• Di REST, lebih sederhana untuk menangani masalah N+1 di controller.

Otorisasi dan masalah N+1

• Kode otorisasi dapat menyebabkan masalah N+1.
• Di REST, masalah ini tidak terjadi.

Coupling

• Dalam codebase GraphQL, business logic sangat terikat dengan lapisan transport.
• Diperlukan integration test, dan debugging menjadi sulit.

Kompleksitas

• Berbagai cara untuk mengatasi masalah keamanan dan kinerja GraphQL meningkatkan kompleksitas codebase.
• Solusi REST umumnya lebih sederhana.

Alternatif

• Disarankan JSON REST API yang menggunakan OpenAPI 3.0+.
• Jika ada klien yang ditulis dengan bahasa bertipe statis, OpenAPI bisa menjadi pilihan yang lebih baik.
• OpenAPI dapat secara otomatis menghasilkan kode klien yang type-safe.

Pendapat GN⁺

• GraphQL memang kuat, tetapi membutuhkan banyak upaya untuk mengatasi masalah keamanan dan kinerja.
• REST API relatif sederhana, dan dalam banyak kasus bisa lebih cocok.
• OpenAPI dapat menyediakan type safety dan alat otomatis untuk meningkatkan produktivitas pengembangan.
• Saat mengadopsi GraphQL, masalah keamanan dan kinerja harus dipertimbangkan secara matang.
• Penting untuk membandingkan kelebihan dan kekurangan REST dan GraphQL lalu memilih teknologi yang sesuai dengan proyek.

[savvykang]

Alasan berhenti memakai GraphQL setelah 6 tahun

[yangeok]

Era ledakan besar RPC akan datang

[ahwjdekf]

Ya begitulah... cuma karena muncul sesuatu yang terlihat fancy, bukan berarti harus langsung ditelan mentah-mentah dan dipuja-puja.. sekarang giliran ORM. Kamu juga tidak lama lagi...

[rockmkd]

ORM sudah ada lebih dari 20 tahun...

[cometkim]

Pada 2018, PQ seharusnya sudah bukan hal yang terlalu baru lagi (sebenarnya sudah direkomendasikan sejak GraphQL pertama kali diumumkan), jadi cukup mengejutkan bahwa mereka tidak mencobanya selama 6 tahun...

[surfindia]

Sulit untuk mengimplementasikan seluruh GraphQL sendiri karena semua alasan yang disebutkan di atas, baik dari sisi kompleksitas maupun stabilitas. Sepertinya lebih baik mengembangkan dengan menempatkan layer seperti hasura atau postgraphile di atas DB, lalu menambahkan graphql atau rest ke layer ini sesuai kebutuhan.

[GN⁺]

Opini Hacker News

• Setelah mengadopsi GraphQL, mereka mengalami banyak masalah. Karena kendala manajemen izin dan performa, mereka tidak ingin lagi menggunakannya. Mungkin cocok jika dipakai hanya di frontend, tetapi integrasinya dengan backend rumit.
• Setelah mempelajari REST terlebih dahulu lalu mencoba gRPC, API yang type-safe terasa menarik. GraphQL tidak punya banyak keunggulan, dan hanya berguna saat berperilaku seperti database.
• Pernah bekerja di dua proyek GraphQL; awalnya dimulai kecil, tetapi seiring waktu menjadi kompleks. Sulit di-debug dan menimbulkan masalah performa. REST dan RPC lebih sederhana serta lebih mudah dikelola.
• Sebagai pendiri Hasura, ia telah melihat evolusi penggunaan GraphQL. GraphQL sangat sulit dibangun tanpa data layer. Menggunakan GraphQL di atas REST tidak efisien. Use case utama GraphQL adalah ketika ada banyak konsumen data.
• Para engineer frontend menyimpan query di library terpusat dan menggunakannya kembali, yang pada dasarnya sama saja dengan menggunakan GraphQL seperti REST.
• Berdasarkan pengalaman menggunakan OpenAPI, GraphQL, JSON/HTTP, dan gRPC, membatasi query GraphQL dapat meredakan masalah performa dan keamanan. Buf Connect adalah titik kompromi yang paling cocok untuk sebagian besar proyek.
• Dari pengalaman menggunakan GraphQL di Facebook, banyak orang sebenarnya tidak memiliki masalah yang ingin diselesaikan oleh GraphQL. Facebook memakai GraphQL untuk menangani versioning dan model objek yang kompleks.
• Alasan GraphQL bekerja baik di Facebook adalah karena semua pengguna login, dan keamanan sudah melekat pada setiap field. Jika ada SPA dan kebutuhan login, GraphQL bisa berguna.
• Setelah mencoba GraphQL, awalnya terasa bagus, tetapi pada akhirnya memerlukan banyak pekerjaan tambahan dan duplikasi. Akan lebih baik memulai dengan endpoint bergaya JSON-RPC lalu menambahkan fitur yang diperlukan.
• Saat menggunakan GraphQL di proyek kecil, hampir semua bagiannya terasa bagus. Dengan Apollo Client dan graphql-codegen, mereka membuat type dan function untuk Vue 3. Ada beberapa masalah, tetapi banyak error bisa ditangkap pada level type.