GraphQL'in herhangi bir dezavantajı var mı? [kapalı]

101

GraphQL hakkındaki tüm makaleler size bunun ne kadar harika olduğunu söyleyecektir, ancak herhangi bir dezavantajı veya dezavantajı var mı? Teşekkür ederim.

rest  restful-authentication  graphql 
— Dr. Nemo
kaynak

Yanıtlar:

96

Dezavantajları:

  • Sen öğrenmemiz gerekiyor GraphQL nasıl ayarlanacağı. Ekosistem hala hızla gelişiyor, bu yüzden ayak uydurmanız gerekiyor.
  • Sen, sadece dizeleri gönderebilirsiniz istemciden sorguları göndermek gerekir ancak daha fazla konfor istiyor ve önbelleğe eğer bir istemci kitaplığı kullanacağız -> ekstra kod İstemcinizdeki
  • Şemayı önceden tanımlamanız gerekir => sonuçları almadan önce ekstra çalışma
  • Sunucunuzda bir graphql uç noktasına ihtiyacınız var => henüz bilmediğiniz yeni kitaplıklar
  • Graphql sorguları, yalnızca bir REST uç noktasına gitmekten daha fazla bayttır
  • Sunucunun sorguyu ayrıştırmak ve parametreleri doğrulamak için daha fazla işlem yapması gerekiyor

Ancak bunlara karşı olanlar bunlardan daha fazlasıdır:

  • GraphQL öğrenmek o kadar da zor değil
  • Ekstra kod sadece birkaç KB
  • Bir şema tanımlayarak, daha sonra hataları düzelterek ve zorlu yükseltmelere katlanarak çok daha fazla çalışmayı önleyeceksiniz.
  • GraphQL'e geçiş yapan pek çok insan var, bu yüzden mükemmel araçlarla gelişen zengin bir ekosistem var.
  • Üretimde kalıcı sorguları kullanıldığında (sadece bir kimlik ve parametrelerle GraphQL sorguları yerine), gerçekte göndermek daha az bayt REST ile daha
  • Gelen sorgular için ekstra işlem ihmal edilebilir
  • Temiz bir API ve arka uç ayrımı sağlamak, arka uç iyileştirmelerinde çok daha hızlı yineleme sağlar
— w00t
kaynak
1
"Şemayı önceden tanımlamanız gerekir => sonuçları almadan önce fazladan çalışma" GraphQL olmadan bunun nasıl gerekli olmadığını anlamıyorum? Elbette bazı dillerdeki bazı çerçevelerde gerekli değildir, ancak örneğin bir Java API'si için modellerinizdeki "şemayı" tanımlamanız gerekir.
— AntoineB
3
@AntoineB haklısınız, NodeJS'de ancak genel şemayı hiç düşünmeden kolayca bir REST API'si yapabilirsiniz; sadece bir şeyler iade et.
— w00t
1
@ w00t ve REST ile bazı parametrelere ihtiyaç duyduğunuzda, URL'yi ayrıştırmaya ve paramın türünün doğru olup olmadığını kontrol etmeye, değilse 400 atmaya başvuracaksınız. Keşke bunu her rota işleyicisinde manuel olarak yapmaktan kaçınılması gereken bir şey olsaydı: D
— Capaj
Bahar Boot ile sadece bazı eserler çekebilir graphql-spring-boot-starterve graphql-java-toolsbaşlamak için. Şemanızı .graphqls kaynağında oluşturun ve Çözümleyici sınıfları oluşturun ve işiniz bitti. Çalışan bir test örneği elde etmek yaklaşık 10 dakika sürdü.
— Babyburger
1
Tüm dezavantajları kabul etmiyorum, aslında size çok zaman kazandırıyor bu yazıyı
— Shafqat Ali
59

GraphQL kullanmayı düşünen herkes için bazı önemli endişeler buldum ve şimdiye kadar ana noktalar şunlar:

Belirsiz Derinlikte Sorgu : GraphQL belirsiz derinlikte sorgulama yapamaz, bu nedenle bir ağacınız varsa ve derinliği bilmeden bir dalı döndürmek istiyorsanız, biraz sayfalandırma yapmanız gerekir.

Spesifik Yanıt Yapısı : GraphQL'de yanıt, sorgunun şekline uymaktadır, bu nedenle çok özel bir yapıda yanıt vermeniz gerekiyorsa, yanıtı yeniden şekillendirmek için bir dönüştürme katmanı eklemeniz gerekir.

Ağ Düzeyinde Önbellek : GraphQL'in yaygın olarak HTTP üzerinden (tek bir uç noktada A POST) kullanılması nedeniyle, ağ düzeyinde önbellek zorlaşır. Bunu çözmenin bir yolu Kalıcı Sorguları kullanmaktır.

Dosya Yüklemeyi Yönetme: GraphQL belirtiminde dosya yüklemeyle ilgili hiçbir şey yoktur ve mutasyonlar bağımsız değişkenlerdeki dosyaları kabul etmez. Bunu çözmek için, diğer tür API'leri (REST gibi) kullanarak dosyaları yükleyebilir ve yüklenen dosyanın URL'sini GraphQL mutasyonuna iletebilir veya dosyayı yürütme bağlamında enjekte edebilirsiniz, böylece dosyayı çözümleyici işlevlerinin içine almış olursunuz.

Öngörülemeyen Yürütme : GraphQL'in doğası, istediğiniz alanları birleştirerek sorgulama yapabilmenizdir, ancak bu esneklik ücretsiz değildir. Performans ve N + 1 Sorguları gibi bilinmesi iyi olan bazı endişeler var.

Süper Basit API'ler : Gerçekten basit bir API ortaya çıkaran bir hizmetiniz olması durumunda, GraphQL yalnızca fazladan bir karmaşıklık ekleyecektir, bu nedenle basit bir REST API daha iyi olabilir.

— Bruno Soares
kaynak
2
Belirsiz derinlik için JsonType yanıtlarına başvuruyorum. Kesinlikle yazılmış değil, bu yüzden girişleri kontrol etmeniz gerekiyor, ancak çok kullanışlı olabilir.
— w00t
3
REST'te her zaman N + 1 Sorgu sorunu vardı. Tek fark, tasarım gereği REST'in arka uca sorunu çözme girişimine bile izin vermemesidir. Bunun yerine sorunu ön uçta iter.
— Capaj
40

GraphQL ile gördüğüm en büyük sorun, yani ilişkisel veritabanı ile kullanıyorsanız, birleşimlerle ilgili .

  1. Birkaç alana izin verebilmeniz / izin vermemeniz, birleştirmeleri önemsiz hale getirir (basit değil). Bu da ekstra sorgulara yol açar.

  2. Ayrıca dairesel sorgulara graphql derivasyonlarda sorguları Yuvalanmış edebilir sunucunun çökmesine . Ekstra özen gösterilmelidir.

  3. Çağrıların hız sınırlaması zorlaşır çünkü artık kullanıcı tek bir çağrıda birden fazla sorgu çalıştırabilir.

İPUCU : JavaScript / düğüm durumunda sorgu sayısını azaltmak için facebook'un veri yükleyicisini kullanın

— aWebDeveloper
kaynak
1. Seçilmiş alanlar operasyonlara katılmakla nasıl ilgilidir? 2. Bir veri yükleyici kullanıyorsanız, hayır. 3. costİsteği ayrıştırabilir ve atayabilirsiniz . Ayrıca, istemcinin yalnızca kimliği gönderdiği önceden tanımlanmış sorgular kullanıyorsanız, bu bir sorun oluşturmaz.
— zoran404
1
2. ile aynı fikirdeyim. 3 ile yaptığı ekstra iş ve daha da önemlisi ppl'nin farkında olması gerekiyor.
— aWebDeveloper
1
2. Sunucunuzu korumak için birçok araç kullanabileceğiniz için bu artık doğru değil. Örneğin bir bağlantı: howtographql.com/advanced/4-security Zaman Aşımları, karmaşıklık ve derinlik sınırı. Yani, oran sınırlayıcı kullanmayacaksanız, REST'inizin DDoS için mümkün olacağını söyleyeceğiniz gibi. İşler değişti
— Yevhenii Herasymchuk
güncellenen nokta 2
— aWebDeveloper
14

Her yıl daha iyi ve daha iyi hale geliyor ve şimdilik GraphQL topluluğu büyüyor ve sonuç olarak, daha önce diğer yanıtlarda vurgulanan birçok soruna çok daha fazla çözüm var. Ancak, şirketleri hala tüm kaynakları GraphQL'e atmaktan alıkoyan şeyin ne olduğunu kabul etmek için, bazı sorunları ve çözümleri, ardından çözülmemiş olanları listelemek istiyorum.

  • Ağ Düzeyinde Önbellek - Bruno'nun Kalıcı Sorgular olduğunu söylediği gibi ve tabii ki bir istemcide önbelleğe alabilirsiniz ve kimse veri tabanı düzeyinde önbelleğe almayı veya hatta Redis'i kullanmanızı durdurmaz. Ama elbette GraphQL'in yalnızca bir uç noktası olduğu ve her sorgu farklı olduğu için - bu tür bir önbelleğe alma yapmak REST'ten çok daha karmaşıktır.
  • GraphQL'deki iç içe geçmiş sorgular döngüsel sorgulara yol açar ve sunucuyu çökertebilir - çok çeşitli çözümlerle artık sorun değil. Bazıları burada listelenmiştir
  • Dosya Yükleme Taşıma - biz var zaten çok ait çözümleri bunun için

Ancak dezavantaj olarak sayılabilecek birkaç durum daha var:

  • ortak şablon aşırılığı (bununla demek istediğim, örneğin yeni sorgu oluşturmak için şemayı, çözümleyiciyi ve çözümleyicinin içinde GraphQL verilerinizi ve içindeki alanlarınızı nasıl çözeceğinizi açıkça söylemek için, istemci tarafında tam olarak ilgili alanlarla sorgu oluşturun. bu veri)
  • hata işleme - Daha çok REST ile karşılaştırmayla ilgili olduğunu söylemeliyim. Burada apollo ile mümkünama aynı zamanda REST'tekinden çok daha karmaşık
  • kimlik doğrulama ve yetkilendirme - Dediğim gibi ama toplum olağanüstü bir hızla artmaktadır ve orada zaten çiftin arasında çözümleri bu hedef için.

Özetlemek gerekirse, GraphQL yalnızca belirli hedefler için bir araçtır ve elbette tüm sorunların sihirli değneği değildir ve elbette REST'in yerini almaz.

— Yevhenii Herasymchuk
kaynak
4

Tek bir uç noktaya sahip olmak ve tüm verileri açığa çıkarmak gerçekten harika. GraphQL için dikkate alınması gereken noktaları aşağıda buluyorum:

  1. Dosya İndirme / Yükleme'nin uygulanması zorlaşıyor (dizeye dönüştürmek büyük dosyalar için en iyi seçenek olmayabilir)
  2. Hem ön uçta hem de arka uçta çok sayıda standart ve şema kodu.
  3. GraphQL spesifikasyonunda sağlanan sayfalamayı izleyin ve destekleyin.
  4. Alanların sıralanması için özel sıralama ve önceliklendirme mantığına izin verin. Kullanıcı verilerini ve ilişkili grupları ve rolleri alırsak örnek. Bir kullanıcı, verileri kullanıcı adı, grup adı veya rol adına göre çoklu sıralayabilir.
  5. Kimlik Doğrulama ve Yetkilendirme, arka uç çerçevesine bağlı olacaktır.
  6. Her bir graphql komutu için tek bir sorgu başlatmak için arka uç optimizasyonunun ve Veritabanı desteğinin sağlanması zorlaşabilir.

Ayrıca, uygulandıktan sonra Artıları dikkate alınmalıdır:

  1. Yeni öğeleri desteklemek ve mevcut davranışı güncellemek için çok esnektir.

  2. Uygulandıktan sonra bağımsız değişkenler ve özel sıralama kullanarak koşul eklemek kolaydır

  3. Çok sayıda özel filtre kullanın ve oluşturulması gereken tüm eylemlerden kurtulun, örneğin bir kullanıcı argüman olarak id, isim vb. Olabilir ve filtreleme yapabilir. Ayrıca filtreler kullanıcı gruplarına da uygulanabilir.

  4. Tüm GraphQL sorgularını ve mutasyonları içeren dosyalar oluşturarak API'yi test etme kolaylığı.
  5. Mutasyonlar basittir ve kavram anlaşıldığında uygulanması kolaydır.
  6. Birden çok derinlikte veri almanın güçlü yolu.
  7. Voyager ve GraphiQL UI veya Playground desteği, görüntülemeyi ve kullanmayı kolaylaştırır.
  8. Geçerli açıklama yöntemleriyle şemayı tanımlarken dokümantasyon kolaylığı.
— vCillusion
kaynak
3

Bence şu an için graphql arka uç mimarisinin bir parçası olmalı, dosya yüklemek için hala normal bir API'ye ulaşıyorsunuz

— kullanıcı998548
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.