GraphQL biraz sinir bozucu

• GraphQL harika, ama biraz abartılıyor gibi görünüyor
• Başlangıç~orta seviye geliştiriciler sanki YouTube izleyip GraphQL kullanmaya başlıyor; bu pek doğru değil gibi
• Artıları
  • İstenen veriyi kolayca tanımlayabilme
  • Bant genişliğinden tasarruf. İstediğiniz kadarını tek seferde alabilirsiniz
  • Veriyi tüketenler için dokümantasyon oluşturmak kolay
  • Subscription kullanmayı kolaylaştırır
  • API çağrılarını bir araya getirmek mümkün
• Eksileri
  • Gerçekte kullanımı acı verici. Kullandığınız backend bunu sizin dilinizde üretmiyorsa 2 ya da daha fazla tip sistemini yönetmeniz gerekir
  • Map/table/dictionary desteklemiyor. Bu gerçekten büyük bir sorun. İstemeseniz de bir yerde {[key: string] : T} kullanmak zorunda kalıyorsunuz
  • API sürümleme için net bir yöntem yok. Sonunda MyQueryV1.01 MyQueryV1.02 MyQueryV1.03 gibi şeyler yapmaya başlıyorsunuz
• Facebook'un GraphQL için hedeflediği çözüm/problem kümesini siz çözmüyorsanız GraphQL kullanmayın
• Diğer kıdemli geliştiriciler, yeni geliştiricileri bu bataklığa düşmekten kurtaracak hangi bilge sözleri söyleyebilir?

HN yorumları

• GraphQL'in en büyük sorunu, DOS saldırılarına karşı savunmak veya tüm DB'nizi indirmeye çalışan insanları engellemek için ekstra iş yapmanız gerekmesi.
  • Sisteminize aşırı yük bindiren sorgular üretmek çok kolay.
  • Neler yapılması gerektiğini görmek için Shopify'a bakabilirsiniz. Dönen veri miktarına göre rate limit uyguluyorlar, ayrıca cursor ve pagination da kullanıyorlar. İnternette görülen şık GraphQL örneklerinin aksine, şemaları devasa ve çirkin
• GraphQL, büyük teknoloji şirketlerinin yaşadığı organizasyonel sorunları çözmek için harika bir yöntem
  • Örneğin API'yi bakımını yapan ekiple değişiklik talep eden ekip farklıysa
  • Organizasyon büyük olduğunda böyle durumlarda değişiklik için sonsuza kadar beklemek gerekir; GraphQL bunu azaltır
  • Küçük bir organizasyonsa eksik olan kısmı doğrudan kendiniz ekleyemez misiniz?
• İster amaçlanmış olsun ister olmasın, GraphQL frontend geliştiricilerinin backend geliştiricilere olan taleplerinden ayrışıp daha hızlı hareket etmesini sağlıyor
  • Backend geliştiricisi veri modelini oluşturup bunu GraphQL ile açtığında, o backend geliştiricisiyle hayatında hiç konuşmamış bir frontend geliştirici bile bunu hemen kullanabilir
  • Sorguladığı şeyi anında değiştirip istediğini alabilir
  • Herkesin daha hızlı hareket etmesini sağlar
  • Ama bir backend geliştiricisi olarak ben GraphQL'den gerçekten nefret ediyorum

[bichi]

GraphQL biraz sinir bozucu. Aşırı sinir bozucu değil, ama biraz öyle; yine de ekip içi iletişim maliyetini kesin olarak azalttığı için, o zamanda sinir bozan kısımları çözmek daha verimli. Bir de gerçekten çok çirkin görünüyor. Ama ben yine de GraphQL kullanmayı öneriyorum. Zaten kimse çıkıp tRPC kullanalım fikrine katılmayacak. Çoğu insan bir teknolojiyi doğru düzgün kullanmayı denemeden, peşin hükümle reddediyor; bunu aşmak için de çok güçlü bir yetkiyle bastırmak gerekiyor. 1-2 teknoloji için bu yapılabilir ama her şeyi zorla kabul ettirmeye kalkarsanız kaybınız daha büyük olur, o yüzden olmuyor... Sonuçta insanları ikna edebileceğiniz en üst seviye yine GraphQL hıçkırık hıçkırık. Boktan REST, asıl bu gerçekten iletişim maliyeti çok yüksek olan kötü bir taş devri teknolojisi hıçkırık hıçkırık

[alucard]

GeekNews'te gezinirken beni üye olmaya iten bir yazıyla ilk kez karşılaşıyorum. The bad kısmına bir yanıt yazdım.

İstemci/sunucu taraflarının ayrı ayrı baktığında artıları ve eksileri olabilir ama birlikte ele alındığında, sunucu ile istemci arasındaki eksik soyutlama katmanını GraphQL şemasının doldurduğu en büyük value proposition'ı bildiğim halde, genel bir üründe REST'i düşüneceğini söylemek bana kişisel olarak biraz eski bir yaklaşım gibi geliyor.
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
  Sonuçta başka bir deyişle, düzgün kullanılırsa iyi mi demek oluyor? code generation falan artık bu devirde sorun bile değil. Tooling ne kadar gelişti.
• 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
  Production Ready kısmında da değinilmiş ama Type System'in avantajlarını kullanırsanız bunun pek de kafa yorulacak bir mesele olmadığını düşünüyorum. key: string değil, doğrudan doğru alanları tanımlarsınız, olur biter..
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  GraphQL zaten aslında versionless'tır....
  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
  Bu, sanki React için de "Facebook'un çözmeye çalıştığı problemi çözmüyorsanız kullanmayın" demek gibi geliyor bana.

[bichi]

Merhaba, çok doğru söylemişsiniz. Acaba tanışabilir miyiz? Benimle aynı şekilde düşünen insanlara ihtiyacım var. Başkalarını (ekip arkadaşlarını) ikna etmek çok zor.

[alucard]

Haha yorumu geç gördüm..!! Ben GraphQL Korea Slack'te Alucard takma adını kullanıyorum :)

[sixmen]

GraphQL’u nispeten erken dönemde benimsemiştim; o zamanlar açıklamalar daha çok backend odaklıydı. Bu yüzden backend tarafında sanki faydalı olacakmış gibi bir algı oluşmuş olabilir diye düşünüyorum.

Ben çeşitli denemeler ve bolca uğraşmanın ardından, sonradan şirkete katılanlar ya da mülakata girenler soru sorduğunda bunu şöyle açıklıyorum: backend için zorlayıcı ama frontend için iyi. :)

[bbulbum]

#Ama backend geliştiricisi olarak ben GraphQL'den gerçekten nefret ediyorum
Katılıyorum..

[ifmkl]

Tam da "doğru araç doğru yerde" sözü akla geliyor.

[kbumsik]

İster kasıtlı olsun ister olmasın, GraphQL frontend geliştiricilerinin backend geliştiricilere yönelik taleplerden ayrışıp daha hızlı hareket etmesini sağlıyor

GraphQL kullanma sebebi bu. GraphQL spesifikasyonunda da bunun frontend için olduğu belirtiliyor 1
Ben de yeni bir startup'ta GraphQL kullanmaya başladım ve eskisine kıyasla API yüzünden frontend mühendisiyle iletişim kurmam gereken sayının belirgin biçimde azaldığını düşünüyorum.

GraphQL'i gerçekten kullanmadan önce aklıma bile gelmeyen sorunlar backend mühendisi açısından biraz can sıkıcı olabiliyor, ama REST API tasarımını iyi yapmaya çalışırken kafa patlatmaktan çok daha iyi gibi geliyor.

[hwasurr]

Hiçbir teknoloji kusursuz değildir! Bence bir teknolojinin eksilerini gidermek için katlanılan maliyete değecek kadar gerekli olması ya da başka, daha büyük bir sorunu çözmesi durumunda onu benimsemek düşünülebilir. Sonuçta teknoloji/aracın uygunluğu her zaman kullanıcının içinde bulunduğu duruma göre belirlenir.

Öte yandan, GraphQL'in eleştirilmesinin nedenlerinden biri de sanırım "kolay" olduğu yönünde bir imaj yaratması olabilir.

[jjpark78]

GraphQL ilk çıktığında onunla bir POC projesi yürütürken, multipart'ı düzgün destekleyen bir motor olmadığı için epey zorlandığımı hatırlıyorum..

[gjen6s]

Ben de eskiden beri küçük ölçekli projelerde GraphQL kullanıldığını görünce bunun fazla abartılı bir tercih olup olmadığını çok düşünürdüm.. demek ki herkes benzer düşünüyor

[xguru]

Sadece ilk yorumları çevirdim. 400'den fazla yorum yapıldığı için hepsini okumak bile zor.