Mimari, statik analiz, dinamik yük testi ve şema yönetişimini birleştiren çok katmanlı bir doğrulama yaklaşımını gerektirir. İlk olarak, yürütmeden önce karmaşıklık puanlarını hesaplamak için GraphQL şema introspeksiyonu kullanarak statik analizi uygulayın ve yapılandırılabilir eşikleri aşan sorguları reddedin. İkinci olarak, yüksek yükte iç içe geçmiş sorguları simüle etmek için k6 veya Artillery ile dinamik analizi kullanarak kaynak tüketimini tespit edin. Üçüncü olarak, federasyon için, CI'de alt grafik uyumluluğunu ve geçit dikiş mantığını doğrulamak üzere Apollo Federation bileşim kontrollerinden yararlanın. Bunu, şema doğrulamaları için özel eşleştiricilerle birlikte Jest ile Node.js test aracı içine entegre edin, böylece sözleşmeler servis sınırları boyunca sağlam kalır.

Hayattan Bir Durum

Bir fintech şirketi, mikro hizmetleri için REST'ten Apollo Federation'a geçiş yaptı. Geçiş sonrası, mobil istemcilerin kullanıcı->hesaplar->işlemler->denetim günlüklerini alırken, üstel karmaşık iç içe geçmiş sorgular göndermesi dolayısıyla üretimde kesintiler yaşandı, bu da PostgreSQL CPU zirvelerine yol açtı.

Çözüm A: İstemci tarayıcı sorgu beyaz listesi

Ekip, yalnızca önceden kaydedilmiş işlemlerle izin verilen sıkı bir kabul listesi tutmayı düşünüyordu. Bu yaklaşım, yalnızca önceden kaydedilmiş işlemlere izin vererek güvenliği garanti eder. Ancak, sıkı istemci koordinasyonu gerektirir, meşru dahili araçlar için rastgele keşfi engeller ve mobil sürümler ile arka uç şema güncellemeleri arasında dağıtım bağımlılığı yaratır.

Çözüm B: Derinlik sınırlayıcı ara yazılım

Beş seviyede iç içe geçişi sınırlandırmak için basit bir derinlik sınırlayıcı (örneğin, graphql-depth-limit kütüphanesi) uygulama önerildi. Hafif ve dağıtması kolay olmasına rağmen, alan düzeyindeki karmaşıklığı dikkate almaz; derinlik üç olan bir sorgu, liste alanları aracılığıyla binlerce kayıt istiyorsa, tek nesnelerle derinlik beş olan bir sorgudan daha fazla kaynak tüketir.

Çözüm C: Alan maliyet analizi ile karmaşıklık puanlaması

Seçilen çözüm, alanlara altındaki SQL sorgu maliyetlerine dayalı sayısal maliyet ağırlıkları atamayı içeriyordu (örneğin, skalar=1, liste=10, yinelemeli=50). Çerçeve, yürütmeden önce toplam sorgu maliyetini hesaplar ve 1000 puanı aşan istekleri reddeder. Bu, koruma ile esnekliği dengeler.

const { createComplexityLimitRule } = require('graphql-validation-complexity');
const rule = createComplexityLimitRule(1000, {
  onComplete: (c) => console.log(`Karmaşıklık: ${c}`)
});

Seçilen çözüm

Ekip, iç analitik takımların ihtiyaç duyduğu GraphQL keşfinin dinamik doğasına zarar vermeden ayrıntılı kontrol sağladığı için Çözüm C'yi seçti. Beyaz liste ile karşılaştırıldığında, meşru karmaşık sorguları engellemedi ve basit derinlik sınırlayıcısıyla karşılaştırıldığında veri tabanı yükünü doğru bir şekilde yansıttı. Bu yaklaşım, istemci dağıtımını güvenlik doğrulamasından ayrıştırdı.

Sonuç

Sonuç, GraphQL esnekliğini korurken üretim kesintilerini ortadan kaldırdı ve zirve yükleri sırasında P95 gecikmesini 4.2 saniyeden 280 milisaniyeye düşürdü. Çerçeve artık CI'de kötü niyetli sorguları otomatik olarak reddediyor ve bunların üretime ulaşmasını engelliyor.

Adayların Sıklıkla Göz Ardı Ettiği Noktalar

GraphQL introspeksiyonunun otomasyon çerçevelerindeki REST şema doğrulamasından farkı nedir?

Pek çok aday, GraphQL şema introspeksiyonunu OpenAPI doğrulamasıyla karıştırır. GraphQL introspeksiyonu, sunucunun tamamı tip sistemini __schema sorgusu aracılığıyla açığa çıkardığı bir çalışma zamanı yansıma yeteneğidir. Bu, otomatik araçların sorguları gerçek yerleştirilmiş şemalara karşı doğrulamasına olanak tanır ve bu da dinamik test üretimi sağlar: çerçeveler, her alan için geçerli sorguları otomatik olarak oluşturmak üzere şemayı tarar, böylece hiçbir çözücü test edilmeden kalmaz. REST'te, sözleşme testleri statik bir Swagger dosyasına karşı doğrulanırken, GraphQL testleri graf yapısının doğasını dikkate almalıdır—geçişlerin iş mantığını ihlal etmediğini doğrulamak, yalnızca HTTP durum kodları değil, yanıt yükü biçimi ve hata uzantıları üzerinde bağlamı dikkate alan doğrulamalar gerektirir.

Neden geleneksel doğrulama desenleri, GraphQL değişikliklerini işlem geri alma ile test ederken başarısız olur?

Adaylar genellikle GraphQL değişikliklerini, testlerden sonra geri dönen veritabanı işlemlerine sarmaya çalışarak REST entegrasyon testlerini taklit ederler. Ancak, GraphQL çözücülerinin, veritabanı geri alma olmaksızın devam eden asenkron yan etkileri (web kancaları, mesaj kuyruk yayınları, üçüncü taraf API aramaları) tetikleyebileceğini unutur. Doğru yaklaşım, her test işçi için izole PostgreSQL örnekleri oluşturmak üzere TestContainers kullanmak ve harici aramaları yakalamak için WireMock ile birleştirmektir. Doğrulamalar, yalnızca değişiklik yanıtını değil, aynı zamanda yakalanan yan etki yüklerini de doğrulamalıdır. Bu, idempotentliği ve uygun olay yayılımını garanti eder—bu, sadece işlem geri alma ile doğrulanamayan kritik yönlerdir ve olay odaklı GraphQL mimarileri için gereklidir.

GraphQL otomasyonunda "N+1 problemi" nedir ve test sırasında bunu nasıl tespit edersiniz?

N+1 problemi, bir çözücünün bir ebeveyn nesne listesi alması, ardından her çocuk alanı için ayrı veritabanı sorguları yürütmesidir. Adaylar, sahte veri yükleyicileri ile birim testlerinin bu sorunu göstermediği için genellikle bunu göz ardı ederler. Otomasyonda, DataLoader toplama doğrulamasını entegre etmelisiniz: test yürütme sırasında SQL sorgularını izlemek için OpenTelemetry kullanın, 100 kullanıcı almanın tam olarak iki sorgu (bir kullanıcılar, bir de profiller için) üretmesini sağlayın, 101 değil. Test aracınızı, sorgu sayıları 1 + (erişilen ayrı varlık türleri sayısı) aşarsa başarısız olacak şekilde yapılandırın. Bu, Dataloader deseninin federasyon alt grafiklerinde doğru şekilde uygulandığını doğrular ve yalnızca gerçek veritabanı hacimlerinde ortaya çıkan üretim performans düşüşlerini engeller.