6 Yılın Ardından GraphQL'den Vazgeçmemin Nedeni

• 2018'den itibaren 6 yıl kullandıktan sonra, gerçek bir GraphQL tutkunu olmama rağmen artık şüphe duymaya başladım
• Artık neden GraphQL önermediğimi ve daha iyi alternatifin ne olduğunu düşündüğümü açıklamak istiyorum

Saldırı yüzeyi

• GraphQL, sorgu dilini dışa açarak saldırı yüzeyini genişletme riski taşır.
• Yetkilendirmeyle ilgili sorunlar özellikle önemlidir.
  • Her alan için uygun yetki kontrolleri gerekir.
  • REST API'de yetkiyi her endpoint bazında kontrol etmek daha basittir.

Yetkilendirme

• Her alan için kullanıcı yetkilerini kontrol etmek gerekir.
• REST API'de yetkiyi her endpoint bazında kontrol etmek daha basittir.

Hız sınırlama

• GraphQL sorgularında boyut sınırı olmadığından sunucu üzerinde büyük yük oluşturabilir.
• Sorgu karmaşıklığını tahmin edip, belirli bir karmaşıklığı aşan sorguları sınırlama yöntemi vardır.
• REST API'de istek sayısını sınırlamak daha basittir.

Sorgu ayrıştırma

• Hatalı sorgu dizeleri sunucunun belleğini aşırı kullanmasına neden olabilir.
• En fazla hata sayısını belirleyerek ayrıştırmayı durdurma yöntemi vardır.

Performans

Veri çekme ve N+1 sorunu

• Alan resolver'ları harici veri kaynaklarını birden çok kez çağırabilir.
• Dataloader pattern kullanılarak bu sorun çözülebilir.
• REST'te N+1 sorununu controller içinde çözmek daha basittir.

Yetkilendirme ve N+1 sorunu

• Yetkilendirme kodu N+1 sorununa yol açabilir.
• REST'te bu sorun ortaya çıkmaz.

Bağımlılık

• GraphQL kod tabanında iş mantığı taşıma katmanına güçlü biçimde bağlıdır.
• Entegrasyon testleri gerekir ve hata ayıklamak zordur.

Karmaşıklık

• GraphQL'in güvenlik ve performans sorunlarını çözmek için kullanılan çeşitli yöntemler kod tabanının karmaşıklığını artırır.
• REST çözümleri genellikle daha basittir.

Alternatifler

• OpenAPI 3.0+ kullanan JSON REST API önerilir.
• Statik tipli bir dilde yazılmış istemciler varsa, OpenAPI daha iyi bir seçim olabilir.
• OpenAPI, tip güvenli istemci kodunu otomatik olarak üretebilir.

GN⁺ görüşü

• GraphQL güçlüdür, ancak güvenlik ve performans sorunlarını çözmek için çok emek gerekir.
• REST API nispeten daha basittir ve birçok durumda daha uygun olabilir.
• OpenAPI, tip güvenliği ve otomatik araçlar sunarak geliştirme verimliliğini artırabilir.
• GraphQL'i benimserken güvenlik ve performans sorunları yeterince dikkate alınmalıdır.
• REST ile GraphQL'in artı ve eksilerini karşılaştırarak projeye uygun teknolojiyi seçmek önemlidir.

[savvykang]

GraphQL biraz sinir bozucu (2022)

[yangeok]

RPC çılgınlığının dönemi geliyor

[ahwjdekf]

Aynen öyle... Sırf havalı bir şey çıktı diye hemen atlayıp bayılmamak lazım.. şimdi sıra ORM'de. Senin de vaktin uzak değil...

[rockmkd]

ORM'ler 20 yılı aşkın süredir var ama...

[cometkim]

2018’de PQ o kadar da yeni sayılmazdı (hatta aslında GraphQL ilk duyurulduğundan beri öneriliyordu); 6 yıl boyunca bunu denememiş olmaları şaşırtıcı...

[surfindia]

GraphQL'yi baştan sona elle tamamen uygulamak, yukarıda bahsedilen tüm nedenlerden dolayı hem karmaşıklık hem de kararlılık açısından zordur. Bence DB'nin üstüne hasura veya postgraphile gibi bir katman koyup, ihtiyaca göre bu katmana ister graphql ister rest ekleyerek geliştirme yapmak daha iyi olur.

[GN⁺]

Hacker News görüşleri

• GraphQL’i benimsedikten sonra birçok sorun yaşadım. Yetki yönetimi ve performans sorunları nedeniyle artık kullanmak istemiyorum. Yalnızca frontend’de kullanılırsa iyi olabilir, ancak backend ile entegrasyonu karmaşık.
• Önce REST’i öğrenip ardından gRPC kullandığımda, tip güvenli API’lerin cazip olduğunu gördüm. GraphQL’in çok fazla avantajı yok ve yalnızca bir veritabanı gibi davrandığında faydalı.
• İki GraphQL projesinde çalıştım; başlangıçta küçük başladılar ama zamanla karmaşıklaştılar. Debug etmek zor ve performans sorunları ortaya çıkıyor. REST ve RPC daha basit ve yönetmesi daha kolay.
• Hasura’nın kurucusu olarak GraphQL kullanımının evrimini gördüm. GraphQL, veri katmanı yoksa inşa edilmesi çok zor. REST’in üzerine GraphQL kullanmak verimsiz. GraphQL’in başlıca kullanım alanı, birden fazla veri tüketicisinin olduğu durumlar.
• Frontend mühendisleri sorguları merkezi bir kütüphanede saklayıp yeniden kullanıyor; bu da GraphQL’i REST gibi kullanmakla aynı şey.
• OpenAPI, GraphQL, JSON/HTTP ve gRPC kullanma deneyimime göre, GraphQL sorgularını sınırlamak performans ve güvenlik sorunlarını hafifletebilir. Buf Connect çoğu proje için en uygun uzlaşma noktası.
• Facebook’ta GraphQL kullanma deneyimime göre, birçok kişi GraphQL’in çözmeye çalıştığı sorunlara sahip değil. Facebook, sürümleme ve karmaşık nesne modellerini ele almak için GraphQL kullanıyor.
• Facebook’ta GraphQL’in iyi çalışmasının nedeni, tüm kullanıcıların giriş yapmış olması ve güvenliğin her alana gömülü olması. SPA ve giriş yapma gereksinimleri varsa GraphQL faydalı olabilir.
• GraphQL kullandığımda ilk başta iyiydi, ama sonunda çok fazla ek iş ve tekrar gerektirdi. JSON-RPC tipinde endpoint’lerle başlayıp gereken özellikleri eklemek daha iyi olurdu.
• Küçük bir projede GraphQL kullandığımda neredeyse her yönünü beğendim. Vue 3 için tipler ve fonksiyonlar üretmek üzere Apollo Client ve graphql-codegen kullandım. Bazı sorunlar vardı ama tip seviyesinde birçok hatayı yakaladı.