🙅‍♀️ Mengapa GraphQL tidak seharusnya ada di inti WordPress

Ya, Anda membaca judul itu dengan benar. Meskipun saya sendiri adalah pencipta server GraphQL untuk WordPress, saya telah mengubah pendapat saya mengenai apakah WordPress seharusnya dilengkapi dengan GraphQL atau tidak.

Tidak lama yang lalu, saya percaya bahwa GraphQL seharusnya ada di inti WordPress. Logikanya adalah bahwa para kontributor menghabiskan waktu dan tenaga untuk mengimplementasikan fungsionalitas bagi WP REST API (operasi batch) yang secara alami dimiliki GraphQL.

Namun, belakangan ini saya mempelajari beberapa informasi baru yang membuat saya berpikir ulang, dan sekarang saya percaya WordPress tidak seharusnya dilengkapi dengan GraphQL, karena risiko tambahan yang ditimbulkannya.

Inilah alasan-alasan saya.

​

1. Tidak memenuhi aturan 80/20

Secara historis, fungsionalitas tertentu ditambahkan ke inti WordPress hanya jika memenuhi aturan 80/20, yang berarti 80% atau lebih pengguna akan menggunakannya.

Apakah itu yang terjadi dengan GraphQL? Saya rasa jawabannya adalah "tidak", berdasarkan preseden dari pengenalan WP REST API ke WordPress 4.7.

Dalam ceramahnya WordPress as Data, 5 Years In, K. Adam White (pemimpin utama pengembangan awal dan rilis WP REST API) menggambarkan bahwa para kontributor mengharapkan REST API akan digunakan secara luas setelah dirilis bersama inti. Namun hal itu tidak terjadi: para pengembang terus membuat situs WordPress dengan cara yang sama seperti sebelumnya, dengan sedikit perhatian terhadap "headless" atau REST API.

Keberuntungan baru berubah kemudian, dengan diperkenalkannya editor Gutenberg di WordPress 5.0, yang didasarkan pada REST API. Apakah Gutenberg kemudian dapat membenarkan penambahan GraphQL ke inti WordPress?

​

2. Headless sudah dipenuhi melalui REST API

Editor WordPress dapat ditingkatkan dengan server GraphQL asli, memungkinkan pengembang blok untuk menggunakan GraphQL (selain REST API yang sudah ada) untuk mengambil data bagi blok mereka. Selain itu, themes dan plugins dapat memanfaatkan GraphQL untuk mendukung fungsionalitas internal mereka sendiri. Ini adalah alasan kuat untuk menambahkan GraphQL ke inti WordPress.

Namun, WordPress sudah memiliki REST API, dan apa pun yang dapat Anda lakukan dengan GraphQL juga dapat dilakukan dengan REST. Memperkenalkan GraphQL selain REST ibarat membeli BMW ketika Anda sudah mengendarai Toyota. Anda akan mencapai tujuan lebih cepat, dan pengalaman berkendara akan lebih menyenangkan. Namun kedua mobil akan membawa Anda ke tempat yang Anda tuju.

Karena GraphQL tidak akan menyediakan fungsionalitas yang sebelumnya tidak tersedia, maka penyertaannya dalam inti tidak sepenuhnya dibenarkan. GraphQL tentu saja akan meningkatkan pengalaman berinteraksi dengan API, namun hal ini bisa dengan sempurna dianggap sebagai wilayah plugin.

​

3. Themes dan plugins WordPress dapat menggunakan webonyx/graphql-php

Plugin publik tidak dapat mengharuskan sebuah situs web untuk menginstal WPGraphQL atau Gato GraphQL agar dapat menggunakan plugin tersebut, karena hal itu akan mengurangi jangkauan potensial mereka. Dengan demikian, plugin publik tidak dapat mengandalkan GraphQL, dan itu sungguh disayangkan.

Saya memikirkan masalah ini dengan serius, dan saya menemukan solusi potensial: GraphQL API Private, sebuah mesin GraphQL mandiri yang dapat disematkan oleh plugin untuk penggunaan mereka sendiri, didistribusikan sebagai paket Composer. (Saya belum mulai mengerjakan proyek ini.)

Namun kemudian, beberapa minggu yang lalu, sebuah plugin WordPress berbasis GraphQL dirilis. Saya penasaran bagaimana penulisnya melakukannya: apakah menggunakan WPGraphQL atau Gato GraphQL di balik layar? Jadi saya memeriksa kode sumbernya dan, ternyata, plugin itu langsung menggunakan webonyx/graphql-php!

Ini adalah solusi yang menarik, yang menunjukkan bahwa, dengan sedikit usaha, para pengembang saat ini memang memiliki akses ke GraphQL untuk themes dan plugins mereka.

Plugin ini menggunakan GraphQL untuk mengambil entitas datanya sendiri, bukan data WordPress (posts, pengguna, komentar, dll). Dengan demikian, plugin ini tidak perlu membuat ulang skema GraphQL yang berisi model data WordPress, seperti yang dilakukan WPGraphQL dan Gato GraphQL (dan nantinya GraphQL API Private). Oleh karena itu, mengandalkan webonyx/graphql-php masuk akal.

​

4. GraphQL menghadirkan risiko tambahan

Ketiga masalah di atas menunjukkan bahwa GraphQL akan meningkatkan WordPress, meskipun tidak terlalu menarik. Dalam hal ini, kita masih bisa menambahkan GraphQL ke inti WordPress, dan baik mendapat manfaat darinya atau tidak ada yang terjadi.

Namun masalah keempat ini menunjukkan bahwa, jika GraphQL tidak akan menambah banyak nilai bagi WordPress, maka tidak seharusnya ditambahkan, karena risiko tambahan yang dibawanya.

GraphQL rentan terhadap vektor serangan berikut (di antaranya):

• Endpoint tunggal menyediakan akses ke semua informasi dari situs web, sehingga kita bisa memiliki data privat yang terekspos tanpa sengaja.
• Query bisa sangat kompleks dan dapat membebani server web dan database.
• Mutation yang sama dapat dieksekusi beberapa kali dalam satu query, dan beberapa query dapat dieksekusi bersama dalam satu permintaan, memungkinkan penyerang untuk mencoba mendapatkan akses ke back-end dengan memberikan banyak kombinasi nama pengguna/kata sandi.

Serangan-serangan ini bisa sangat merusak. Dalam presentasinya Damn GraphQL - Defending and Attacking APIs, peneliti keamanan siber Dolev Farhi berhasil menjatuhkan sebuah situs WordPress dalam waktu kurang dari 30 detik, dengan menyerang endpoint WPGraphQL menggunakan sekumpulan query yang kompleks.

Tim WPGraphQL segera memperbaiki masalah tersebut. Namun bagaimana kita bisa yakin bahwa tidak ada eksploit lain yang bisa terjadi? (Maksud saya bukan hanya WPGraphQL, tetapi Gato GraphQL juga.)

Serangan-serangan ini dapat terjadi dengan GraphQL, dan tidak dengan REST, karena GraphQL lebih kuat daripada REST. Sementara dalam REST query didefinisikan terlebih dahulu dan disimpan di server, dalam GraphQL query disediakan saat runtime oleh klien (kecuali menggunakan persisted queries).

Jika admin situs web lalai dalam mengonfigurasi siapa yang dapat mengakses endpoint, atau data apa yang terekspos, maka hal-hal buruk bisa terjadi. Dan karena popularitas WordPress, yang digunakan oleh jutaan orang yang tidak melek teknologi, maka kemungkinan besar hal-hal buruk akan terjadi.

​

Penutup

Hanya untuk memastikan: saya tidak menganjurkan untuk tidak menggunakan GraphQL di WordPress (tentu saja tidak!), tetapi untuk menggunakan GraphQL secara bertanggung jawab. GraphQL itu kuat, yang berarti berbahaya. Saat menggunakan GraphQL, kita perlu memastikan bahwa kita tahu apa yang kita lakukan.

Menyertakan GraphQL dalam inti WordPress akan menempatkannya di tangan banyak orang, yang banyak di antaranya tidak akan menyadari risikonya, dan tidak mengambil tindakan yang tepat. Ini adalah resep untuk potensi bencana. Dan oleh karena itu, kini menjadi pendapat saya, hal itu seharusnya dihindari.