Blog

🙅‍♀️ GraphQL neden WordPress core'unda olmamalı

Leonardo Losoviz
Yazan: Leonardo Losoviz ·

Güncelleme 01/05/2024: Gato GraphQL vs WP REST API karşılaştırmasına göz atın.

Evet, başlığı doğru okudunuz. WordPress için bir GraphQL sunucusunun yaratıcısı olmama rağmen, WordPress'in GraphQL ile birlikte gelip gelmemesi gerektiği konusundaki görüşümü değiştirdim.

Çok uzun zaman önce değil, GraphQL'in WordPress core'unda olması gerektiğine inanıyordum. Mantık şuydu: katkıda bulunanlar, GraphQL'e özgü olan WP REST API işlevselliğini (toplu işlemler) uygulamak için zaman ve çaba harcıyordu.

Ancak son zamanlarda bazı yeni bilgiler öğrendim ve bu bilgiler beni yeniden düşündürdü; artık eklenen riskler nedeniyle WordPress'in GraphQL ile birlikte gelmemesi gerektiğine inanıyorum.

WordPress core'unda GraphQL mi? 😁

İşte gerekçelerim.

1. 80/20 kuralını karşılamıyor

Tarihsel olarak, belirli bir işlevsellik yalnızca 80/20 kuralını karşıladığında WordPress core'una eklenir; yani kullanıcıların %80'i veya daha fazlası tarafından kullanılması gerekir.

GraphQL için bu geçerli olur muydu? Bence cevap "hayır"; bunu WP REST API'nin WordPress 4.7'ye dahil edilmesinden önceki emsal kararına dayanarak söylüyorum.

WordPress as Data, 5 Years In adlı konuşmasında K. Adam White (WP REST API'nin ilk geliştirme ve yayınlanmasının ana sorumlusu), katkıda bulunanların REST API'nin core ile birlikte yayınlandığında yaygın olarak kullanılmasını beklediğini anlattı. Ancak bu olmadı: geliştiriciler WordPress sitelerini eskiden olduğu gibi oluşturmaya devam etti, "headless" veya REST API'ye çok az ilgi gösterdi.

Durum ancak daha sonra, REST API'ye dayanan Gutenberg editörünün WordPress 5.0 ile birlikte gelmesiyle değişti. Peki Gutenberg, GraphQL'in WordPress core'una eklenmesini haklı kılabilir mi?

REST API ile beklenen gelecek. K. Adam White'ın konuşmasından ekran görüntüsü

2. Headless zaten REST API ile karşılanıyor

WordPress editörü, blok geliştiricilerinin verilerini almak için GraphQL'i (mevcut REST API'ye ek olarak) kullanmalarına olanak tanıyan yerel bir GraphQL sunucusuyla geliştirilebilir. Ayrıca temalar ve eklentiler, kendi dahili işlevlerini desteklemek için GraphQL'i kullanabilir. Bunlar, GraphQL'i WordPress core'una eklemek için güçlü gerekçelerdir.

Ancak WordPress'in zaten REST API'si var ve GraphQL ile yapabildiğiniz her şeyi REST ile de yapabilirsiniz. REST'e ek olarak GraphQL eklemek, zaten Toyota kullanırken BMW satın almaya benzer. Hedefinize daha hızlı ulaşırsınız ve sürüş deneyimi daha çekici olur. Ama her iki araç da sizi gitmek istediğiniz yere götürür.

GraphQL daha önce mevcut olmayan bir işlevsellik sağlamayacağından, core'a dahil edilmesi tam olarak haklı değildir. GraphQL kesinlikle API ile etkileşim deneyimini geliştirir, ancak bu tamamen eklenti alanı olarak değerlendirilebilir.

GraphQL, API ile etkileşim deneyimini geliştirir, ancak yeni bir şey yaratmaz

3. WordPress temaları ve eklentileri webonyx/graphql-php kullanabilir

Genel eklentiler, bir web sitesinin eklentiyi kullanabilmesi için WPGraphQL veya Gato GraphQL yüklemesini zorunlu kılamaz; çünkü bu, potansiyel erişim alanlarını daraltır. Bu nedenle, genel eklentiler GraphQL'e güvenemez ve bu gerçekten üzücü bir durumdur.

Bu sorun üzerinde uzun süre düşündüm ve olası bir çözüm buldum: GraphQL API Private — eklentilerin kendi kullanımları için gömebileceği, Composer paketi olarak dağıtılan bağımsız bir GraphQL motoru. (Bu proje üzerinde henüz çalışmaya başlamadım.)

Ancak birkaç hafta önce, GraphQL destekli bir WordPress eklentisi yayınlandı. Yazarın bunu nasıl yaptığını merak ettim: WPGraphQL mi yoksa Gato GraphQL mi kullanıyordu? Kaynak koduna baktım ve görünüşe göre doğrudan webonyx/graphql-php kullanıyordu!

Bu ilginç bir çözümdür ve geliştiricilerin biraz çaba harcayarak temalar ve eklentileri için GraphQL'e erişebildiğini göstermektedir.

Bu eklenti, WordPress'in veri varlıklarını (yazılar, kullanıcılar, yorumlar vb.) değil, kendi veri varlıklarını almak için GraphQL kullanıyor. Bu nedenle WPGraphQL ve Gato GraphQL'in (ve nihayetinde GraphQL API Private'ın) yaptığı gibi WordPress veri modelini içeren GraphQL şemasını yeniden oluşturmasına gerek yok. Bu bağlamda webonyx/graphql-php'ye güvenmek mantıklıdır.

webonyx/graphql-php, 'GraphQL referans uygulamasının PHP portu'dur

4. GraphQL ek riskler barındırıyor

Yukarıdaki üç sorun, GraphQL'in son derece zorlayıcı olmasa da WordPress'i geliştireceğini gösteriyor. Bu ışıkta, GraphQL'i WordPress core'una ekleyebilir ve ya bundan yararlanırız ya da hiçbir şey değişmez.

Ancak bu 4. sorun şunu gösteriyor: eğer GraphQL WordPress'e çok fazla değer katmayacaksa, ek riskleri nedeniyle eklenmemesi gerekir.

GraphQL, aşağıdaki saldırı vektörlerine (diğerlerinin yanı sıra) karşı savunmasızdır:

  • Tek endpoint, web sitesindeki tüm bilgilere erişim sağlar; bu nedenle özel veriler istemeden açığa çıkabilir.
  • Queries çok karmaşık olabilir ve web ile veritabanı sunucularını aşırı yükleyebilir.
  • Aynı mutation tek bir query içinde birden fazla kez çalıştırılabilir ve birden fazla query tek bir istekte birlikte çalıştırılabilir; bu da saldırganların birçok kullanıcı/şifre kombinasyonu deneyerek arka uca erişmeye çalışmasına olanak tanır.

Bu saldırılar gerçekten yıkıcı olabilir. Damn GraphQL - Defending and Attacking APIs adlı sunumunda siber güvenlik araştırmacısı Dolev Farhi, karmaşık queries içeren bir toplu işlemle WPGraphQL endpoint'ine saldırarak bir WordPress sitesini 30 saniyeden kısa sürede çökerttmeyi başardı.

WPGraphQL ekibi sorunu hemen düzeltti. Ama başka bir istismarın gerçekleşmeyeceğinden nasıl emin olabiliriz? (Yalnızca WPGraphQL'i değil, Gato GraphQL'i de kastediyorum.)

Bu saldırılar GraphQL ile yaşanabilir; REST ile değil; çünkü GraphQL, REST'ten daha güçlüdür. REST'te query önceden tanımlanıp sunucuda depolanırken, GraphQL'de client tarafından çalışma zamanında sağlanır (persisted queries kullanılmadıkça).

Web sitesi yöneticileri endpoint'e kimin erişebileceğini veya hangi verilerin açığa çıkacağını yapılandırma konusunda dikkatsiz davranırsa, kötü şeyler olabilir. Ve teknolojiye hakim olmayan milyonlarca kişi tarafından kullanılan WordPress'in popülaritesi göz önüne alındığında, kötü şeylerin yaşanması çok büyük ihtimal olacaktır.

GraphQL endpoint'ine saldırarak WordPress sitesini çökertmek. Dolev Farhi'nin konuşmasından ekran görüntüsü

Sonuç

Açık olmak gerekirse: WordPress'te GraphQL kullanmama savunuculuğu yapmıyorum (elbette hayır!); GraphQL'i sorumlu bir şekilde kullanmayı savunuyorum. GraphQL güçlüdür; bu da tehlikeli olduğu anlamına gelir. GraphQL kullanırken ne yaptığımızdan emin olmamız gerekir.

GraphQL'i WordPress core'unda göndermek, onu pek çok insanın eline koyar; bunların büyük bir kısmı risklerinin farkında olmayacak ve uygun önlemleri almayacaktır. Bu, potansiyel bir felaket reçetesidir. Bu nedenle artık benim görüşüme göre bundan kaçınılmalıdır.


Bültenimize abone olun

Gato GraphQL'deki tüm güncellemelerden haberdar olun.