GraphQL Şema Yönetişimi: Yayın Öncesi Kırıcı Değişiklikleri İnceleyin

TL;DR

GraphQL şema yönetişimi, bir şemayı değişirken kullanışlı tutan sürüm disiplinidir. Her sürümden önce şema düzenlemelerini sınıflandırın, temsili istemci işlemlerini test edin, bir kullanımdan kaldırma yolu yayınlayın ve dokümantasyonu doğrulayın. Apidog gibi paylaşımlı bir çalışma alanı; tasarım, istekler, testler, dokümantasyon ve mock çalışmalarına tek bir yuva sağlar.

• GraphQL şemasına dahili bir uygulama detayı değil, genel bir sözleşme olarak davranın.
• Kırıcı değişiklikleri istemcilere ulaşmadan önce tespit edin.
• Eski bir alanı kullanımdan kaldırmadan önce yerine geçecek bir alan ekleyin.
• Kaydedilmiş işlemleri aday şemaya ve yanıt sözleşmesine karşı test edin.
• Sahiplik, inceleme kararları, tüketici etkisi ve kaldırma tarihlerini kaydedin.
• İstemci ekiplerine neyi ne zaman değiştirmeleri gerektiğini söyleyen sürüm notları yayınlayın.

Giriş

GraphQL şema yönetişimi, API sürümlerinin mobil uygulamaları, web istemcilerini, entegrasyonları ve dahili servisleri uyarı olmadan bozmasını engeller. GraphQL istemci sorgularını esnek hale getirir, ancak bir istemci ona bağımlı hale geldiğinde her alan, argüman, enum değeri, null olabilirlik kuralı ve girdi nesnesi yine de bir sözleşmenin parçası haline gelir.

Bu sözleşme sık sık değişir. Bir ürün ekibi displayName adını değiştirir. Bir backend ekibi isteğe bağlı bir girdiyi zorunlu hale getirir. Bir faturalama servisi bir enum değerini kaldırır. Her düzenleme, şema düzenleyicisinde zararsız görünebilirken üretimdeki kaydedilmiş bir işlemi geçersiz kılabilir.

GraphQL spesifikasyonu, GraphQL'in tip sistemini, doğrulama kurallarını ve şema evrimi endişelerini açıklar. Ekiplere ortak dili verir. Yönetişim ise sürüm sürecini sağlar: bir değişikliği kim inceler, ekipler istemci etkisini nasıl değerlendirir, nasıl test eder ve eski alanları sürpriz bir kesinti olmadan nasıl devre dışı bırakır.

Bu makale, bir GraphQL tanıtımından ziyade sürüm kontrolüne odaklanmaktadır. Ekibinizin önce istek düzeyinde bir iş akışına ihtiyacı varsa, Apidog'da GraphQL API'leri nasıl test edilir konusuna bakın. Sonraki adım, bu testleri kalıcı bir şema-değişikliği sürecinin parçası haline getirmektir.

GraphQL şema yönetişimi nedir?

GraphQL şema yönetişimi, şema değişikliklerini sürümden önce gözden geçirmek, test etmek, belgelemek ve onaylamak için tekrarlanabilir bir süreçtir. İstemciyi bozan düzenlemeleri tanımlar, onaylanmış bir geçiş yolu gerektirir ve sahipliği görünür tutar. Amaç, öngörülebilir bir şema evrimidir: istemciler, eski bir sözleşme ortadan kalkmadan önce geçiş yapmaları için zaman ve talimatlar alır.

Yönetişim, bir şemayı dondurmak anlamına gelmez. Sağlıklı bir GraphQL API ürünle birlikte değişir. Süreç, güvenli bir şekilde değişmesini sağlar.

Kullanışlı bir yönetişim politikası, her pull request veya sürüm adayı için beş soruyu yanıtlar:

1. Şemada ne değişti?
2. Hangi değişiklikler daha önce geçerli olan bir istemci işlemini başarısız kılabilir?
3. Etkilenen alanların ve istemci geçişlerinin sahibi kim?
4. Hangi kaydedilmiş işlemler ve yanıt kontrolleri uyumluluğu kanıtlıyor?
5. Kullanımdan kaldırılmış bir alan veya enum değeri ne zaman kaldırılabilir?

Bu sorular, muğlak bir "API incelemesi" talebini bir gözden geçirenin inceleyebileceği kanıtlara dönüştürür.

GraphQL neden açık bir sürüm sürecine ihtiyaç duyar?

GraphQL istemcileri kendi seçim kümelerini oluşturur. İki istemci aynı sorgu kökünü çağırabilirken tamamen farklı alanlara, parçalara, değişkenlere ve takma adlara dayanabilir. Sunucu telemetrisi, kaydedilmiş sorgular ve tüketici-ekibi bilgisi hepsi yardımcı olur, ancak hiçbiri tek başına bir düzenlemenin güvenli olduğunu kanıtlamaz.

Bir değişiklik ayrıca bir sunucu birim testini geçerken doğrulama zamanında bir istemciyi başarısız kılabilir. Bir alanı kaldırmak onu seçen her işlemi geçersiz kılar. Zorunlu bir girdi alanı eklemek onu atlayan işlemleri geçersiz kılabilir. Bir enum'u değiştirmek, üretilmiş bir istemciyi veya kapsamlı switch dalını bir sunucu yanıtını işleyemez hale getirebilir. Null olabilen bir alan tipini farklı bir şekille değiştirmek ayrıştırmayı veya UI varsayımlarını bozabilir.

Aynı gerilim API yönetimi çalışmalarında da ortaya çıkar. Bir GraphQL API yönetim platformu, ekiplerin sözleşme kararlarını, dokümantasyonu ve doğrulamayı API'ye yakın tutmasına yardımcı olmalıdır. Yönetişim, bu yetenekleri bir olaydan sonra değil, bir sürüm sırasında kullanışlı hale getirir.

Şema düzenlemelerini tartışmadan önce sınıflandırın

Her değişikliğe bir sınıflandırmayla başlayın. Etiketlerin karmaşık olması gerekmez. Doğru inceleme yolunu üretmeleri gerekir.

Tablo bir başlangıç noktasıdır. Sözde eklemeli bir değişiklik yine de önemli olabilir. Örneğin, bazı üretilmiş istemciler veya katı yanıt doğrulayıcıları bilinmeyen alanları bir sorun olarak görür. Apidog'un yanıt-doğrulama ayarları varsayılan olarak ek nesne özelliklerine izin verir. Politikanızın beklenmeyen özellikler için bir kontrol gerektirmesi durumunda, ilgili yanıt şeması için additionalProperties değerini Deny olarak ayarlayın veya proje ayarını kasıtlı olarak değiştirin.

Varsayılan olarak bir sürümü durdurması gereken değişiklikler

Aşağıdakilerden herhangi birini içeren bir inceleme açık onay gerektirmelidir:

• Bir alanı, argümanı, girdi alanını, mutasyonu, sorguyu, arayüz uygulamasını, birlik üyesini veya enum değerini kaldırma.
• Bir alanı yeniden adlandırma yerine bir yenisini ekleyip eski adı kullanımdan kaldırma.
• Daha önce isteğe bağlı olan bir girdiyi zorunlu hale getirme.
• Bir alanın tipini, null olabilirlik beklentisini, formatını, yetkilendirme davranışını, sayfalama davranışını veya hata sözleşmesini değiştirme.
• Mevcut bir alan adını farklı bir iş anlamı için yeniden kullanma.
• İstemcilerin kasıtlı olarak atladığı bir varsayılan değeri değiştirme.

Kural basittir: bir istemci sorgusu veya istemci tarafı varsayımı dün çalıştıysa ve yarın başarısız olabiliyorsa, kanıt aksini söyleyene kadar onu kırıcı olarak sınıflandırın.

Kullanımdan kaldırmayı bir geçiş sözleşmesi olarak kullanın

Kullanımdan kaldırma, gerçek bir ileri yol içerdiğinde işe yarar. Yerine geçen, sahip, son tarih veya geçiş notları olmadan "kullanımdan kaldırıldı" demek, kırıcı bir değişikliği yalnızca erteler.

Bir müşteri adı temizliğini düşünün. Alanı yerinde yeniden adlandırmayın:

# Avoid removing fullName in the same release.
type Customer {
 fullName: String!
}

Yerine geçeni ekleyin, nedeni açıklayın, ardından duyurulan pencere boyunca her iki alanı da destekleyin:

type Customer {
 displayName: String!
 fullName: String! @deprecated(reason: "Use displayName. Removal planned after client migration.")
}

Yerine geçen, bir şema açıklamasından daha fazlasına ihtiyaç duyar. Bunu dokümantasyona ekleyin, birinci taraf istemcileri güncelleyin, yüksek değerli tüketicileri belirleyin ve benimsemeyi takip edin. Eski alanı yalnızca geçiş çıkış kriterleri karşılandıktan sonra kaldırın.

Bir GraphQL şema yönetişimi iş akışı oluşturun

Tekrarlanabilir bir iş akışının kontrol noktaları vardır. Acele bir sürüm sırasında her istemci detayını hatırlayan tek bir kişiye bağlı değildir.

1. Bir doğruluk kaynağı ve adlandırılmış sahipler oluşturun

Onaylanmış tek bir şema kaynağı tutun ve katalog, faturalama, kimlik veya karşılama gibi her sınırlı alan için bir sahip atayın. Sahibin her çözümleyiciyi yazması gerekmez. O alandaki sözleşme sorularını yanıtlamaları ve değişiklikleri onaylamaları gerekir.

Bu detayları şema değişikliğinin yanında kaydedin:

• Şema alanı ve sahip ekip.
• Değişiklik sınıflandırması.
• Etkilenen alanı veya işlemi kullandığı bilinen tüketiciler.
• Yerine geçen alan veya geçiş talimatları.
• En erken kaldırma tarihi.
• Aday sürümün çalıştığını kanıtlayan testler.

Bu kayıt, bir alanın terk edilmiş genel yüzey alanı haline gelmesini engeller.

2. Aday şemayı farklılaştırın ve risk atayın

Mevcut sürüm ile aday arasında bir şema farkı oluşturun veya inceleyin. Satır satır bir farkta durmayın. Sonucu istemci etkisine çevirin.

Değişen her tip için, mevcut bir sorgunun geçersiz hale gelip gelemeyeceğini, mevcut bir JSON yanıtının şeklinin değişip değişemeyeceğini ve davranışın tip sistemi değişikliği olmadan değişip değişemeyeceğini sorun. Yetkilendirme kuralları yaygın bir örnektir. Şema aynı kalabilirken daha önce görünür olan bir alan bir yetkilendirme hatası veya null döndürmeye başlayabilir.

Bunun gibi kısa bir değişiklik kaydı kullanın:

change: remove Customer.fullName
type: breaking
owner: customer-platform
replacement: Customer.displayName
deprecated_since: 2026-08-21
planned_removal: 2026-11-21
known_consumers:
 - ios-storefront
 - partner-portal
release_checks:
 - saved-operation-suite
 - client-migration-confirmations
 - published-release-notes

Tarihler örnektir. Politikanız, sürüm sıklığına, istemci güncelleme hızına ve sözleşmesel taahhütlere uyan bir kullanımdan kaldırma penceresi belirlemelidir.

3. Yalnızca şema söz dizimini değil, gerçek işlemleri test edin

Bir şema ayrıştırılabilir ve yine de bir istemciyi bozabilir. Her büyük tüketici veya kullanıcı yolculuğu için temsili işlemlerden oluşan bir set tutun. Parçaları, değişkenleri, sayfalamayı, izin sınırlarını, hataları ve isteğe bağlı alanları dahil edin.

Bir mağaza vitrini için set şunları içerebilir:

query ProductPage($sku: ID!, $first: Int!) {
 product(sku: $sku) {
 id
 displayName
 price {
 amount
 currency
 }
 relatedProducts(first: $first) {
 nodes {
 id
 displayName
 }
 }
 }
}

İşlemi aday ortama karşı çalıştırın. HTTP durumunu, GraphQL hatalarını, gerekli yanıt değerlerini, tip beklentilerini ve istemci için önemli olan iş kurallarını doğrulayın. HTTP 200 ve bir errors dizisi içeren bir yanıt, birçok kullanım durumu için başarılı bir GraphQL işlemi değildir.

Gerçek uç durumları kapsayan istek fikstürleri kullanın: boş listeler, boş isteğe bağlı alanlar, silinmiş kaynaklar, izin reddi, yerel ayar farklılıkları ve eski imleçler. Kaydedilmiş işlemler bir sürüm kararının arkasındaki kanıt haline gelir.

4. Dokümantasyonu kapının bir parçası yapın

Dokümantasyonun şemayla aynı inceleme tarihine ihtiyacı vardır. Var olan ancak açıklama, örnek, izin notları veya geçiş rehberliği olmayan bir alan, istemci ekiplerini amacı tersine mühendislikle çözmeye zorlar.

Etkilenen her alan veya girdi için kontrol edin:

• Açıklama, çözümleyici davranışı yerine iş anlamını mı açıklıyor?
• Null olabilirlik ve varsayılan değer beklentileri net mi?
• Kullanımdan kaldırılmış bir alan yerine geçeni belirtiyor mu?
• İlgili örnekler yeni alanı kullanıyor mu?
• Değişiklik günlüğü eylemi, hedef kitleyi ve kaldırma tarihini açıklıyor mu?

Burasi aynı zamanda ekiplerin, yalnızca introspection mevcut olduğunda çalışan GraphQL şeması sorununu önlediği yerdir. Yayımlanan referans materyalleri ve sürüm notları, harici istemciler ve kısıtlı ortamlar için kendi başlarına ayakta durmalıdır.

5. Yayınlayın, gözlemleyin ve kanıta dayalı olarak kaldırın

Değişiklik sınıflandırmasını ve geçiş notlarını kaldırma son tarihinden önce yayınlayın. Mevcut olduğunda şema-farkında telemetri ile istemci geçişini, harici tüketiciler için partner onayını ve birinci taraf ekiplerinden tamamlama kanıtını takip edin.

Bitiş tarihi geldiğinde, kaydedilmiş işlem setini tekrar çalıştırın. Kritik işlemler hâlâ kullanımdan kaldırılmış alanı kullanıyorsa, kaldırmayı erteleyin. Eski bir alan, önlenebilir bir istemci kesintisinden daha ucuza mal olur.

İncelemeyi tekrarlanabilir kılmak için Apidog'u kullanın

Apidog, API ekiplerine tasarım, hata ayıklama, test, dokümantasyon ve mock'lar için tek bir çalışma alanı sağlar. Bir GraphQL yönetişim süreci için faydalı hedef, her sürüm adımı için ayrı bir araç değil, paylaşılan bir inceleme izidir.

Apidog'da Body > GraphQL üzerinden bir GraphQL isteği oluşturun, ardından şemayı yüklemek için Fetch Schema'yı kullanın. GraphQL düzenleyicisi, alan ve tip önerileri için alınan şemayı kullanır ve sorguları buna göre kontrol eder. Bir ekip iş akışı yapılandırmadan önce resmi GraphQL istek dokümantasyonunu okuyun.

Pratik bir sürüm kurulumu şöyle görünür:

1. Her kritik akış için temsili sorguları ve mutasyonları kaydedin.
2. Ortama özgü değişkenleri sorgunun dışına koyun, böylece işlem şekli sabit kalır.
3. Durum, başlıklar, JSON yanıt şekli, gerekli alanlar, enum'lar ve hata davranışı için doğrulamalar ekleyin.
4. Kontrolleri aday ortam için bir sürüm setinde gruplandırın.
5. Onaydan önce başarısız kontrolleri şema farkı ve değişiklik kaydıyla inceleyin.
6. Dokümantasyonu ve geçiş notlarını aynı onaylanmış API sözleşmesinden yayınlayın.

Yanıt doğrulaması durumu, formatı ve şema uygunluğunu kontrol eder. Belgelenen kontroller, JSON ve XML yanıtları için gerekli alanları, tipleri, null olabilirliği, enum değerlerini, aralıkları ve desenleri içerir. Bu, onu GraphQL yanıt gövdeleri için kullanışlı kılar çünkü GraphQL yanıtları JSON kullanır. Bir GraphQL şema-farkı aracının veya tüketici envanterinin yerini almaz. Her ikisiyle birlikte kullanın.

Ekibiniz istek düzeyindeki testlerden başlıyorsa, GraphQL test ve mock araçları test katmanını çerçevelemeye yardımcı olabilir. Yönetişim bu testlerin etrafına sürüm kaydını, sahipliği ve kullanımdan kaldırma politikasını ekler.

Tasarım, istek, yanıt doğrulama, dokümantasyon ve mock iş akışını tek bir çalışma alanında istediğinizde Apidog'u indirin. Yönetişim politikasını deponuzda tutun ve her sürüm incelemesine somut test kanıtı sağlamak için çalışma alanını kullanın.

Daha büyük GraphQL API'leri için ileri teknikler

Tüketici katmanlarını tanımlayın

Her istemci aynı sürüm riskini taşımaz. Tüketicileri etkiye ve yükseltme hızına göre sınıflandırın:

Katmanlar, küçük bir dahili deneyin bir ödeme akışıyla aynı sürüm yükünü dayatmasını engeller. Ayrıca kritik bir harici entegrasyonun izlenmeyen bir sorgu gibi ele alınmasını engeller.

Şemanın dışındaki davranış değişikliklerini takip edin

Şema farkları her sözleşme değişikliğini tespit edemez. Şunlar için inceleme soruları ekleyin:

• Yetkilendirme ve alan düzeyinde erişim.
• Sayfalama sıralaması, imleç ömrü ve sayfa boyutu sınırları.
• Önbellekleme davranışı ve geçersiz kılma zamanlaması.
• Hata uzantıları ve kullanıcıya görünen hata mesajları.
• Hız sınırı davranışı ve yeniden deneme rehberliği.
• Geçerli bir işlemi güvenilmez hale getiren çözümleyici performansı.

Planlanan her davranış değişikliği için hedefli bir test yazın. Bu, yüzeysel bir "kırıcı şema değişikliği yok" etiketinin bir sürüm geçişi haline gelmesini engeller.

Federasyon sınırlarını sözleşme sınırları olarak ele alın

Birden fazla ekip alt grafiklere katkıda bulunuyorsa, her paylaşılan varlık, anahtar ve alt grafikler arası alan açık sahiplik gerektirir. Bir alan bir ekibe yerel görünebilirken başka bir alt grafik onu genişletir veya tüketir.

Değişiklik kaydında etkilenen alt grafiklerin bir listesini isteyin. Oluşturulmuş şema davranışını ve sınırı geçen uçtan uca bir işlemi test edin. Temiz bir yerel şema kontrolü, oluşturulmuş grafiğin çalıştığını kanıtlamaz.

Bir istisna yolu belirleyin

Acil kaldırmalar, bir alan veriyi açığa çıkardığında, bir güvenlik sorunu oluşturduğunda veya ciddi operasyonel zarara neden olduğunda gerçekleşir. Yönetişimin bir istisna yoluna ihtiyacı vardır, böylece ekipler baskı altında dokümantasyonu ve testi atlamaz.

İstisna kaydı riski, onaylayan sahibi, etkilenen tüketicileri, hafifletmeyi ve takip planını belirtmelidir. Normal kullanımdan kaldırma penceresi mümkün olmadığında tüketicileri doğrudan bilgilendirin. Ardından aynı hatanın geri dönmemesi için bir regresyon testi ekleyin.

Alternatifler ve sınırlar

Bir şema kaydı, bir federasyon ağ geçidi, üretilmiş bir istemci veya bir CI şema-farkı kontrolü hepsi yardımcı olabilir. Hiçbiri tüm sürecin yerini almaz.

API'niz için güvenilir kanıt üreten en küçük yığını seçin. Ekibiniz GraphQL'in yeni bir servise uyup uymadığına karar veriyorsa, istemci odaklı sorgu modelini REST ve gRPC ile REST vs GraphQL vs gRPC içinde karşılaştırın. Protokol seçimi ve sürüm yönetişimi ayrı kararlardır. Her genel sözleşme yine de her ikisine de ihtiyaç duyar.

Gerçek dünya kullanım durumları

Bir mobil uygulama yeniden adlandırılmış bir profil alanına ihtiyaç duyar

Bir profil ekibi, kuruluş hesapları farklı bir adlandırma modeli kullandığı için fullName yerine displayName koymak ister. Yönetişim yolu, bir sürümün ardından gelen bir yeniden adlandırma commit'i değildir.

displayName ekleyin, fullName öğesini bir kullanımdan kaldırma nedeniyle koruyun, mobil sorguyu güncelleyin, geçiş sırasında her iki alanı test edin ve uygulama sürümüne göre benimseme verilerini toplayın. fullName öğesini yalnızca desteklenen uygulama sürümleri artık ona bağımlı olmadıktan sonra veya yayımlanan destek penceresi sona erdikten sonra kaldırın.

Bir ödeme mutasyonu yeni bir girdi gereksinimi alır

Bir ödeme ekibi CheckoutInput.taxRegion değerinin zorunlu hale gelmesini ister. Mevcut uygulama sürümleri bu değeri atlar. Girdiyi hemen zorunlu hale getirmek, aksi takdirde geçerli olan ödeme işlemlerini doğrulamada başarısız kılabilir.

Geçiş sırasında girdiyi isteğe bağlı tutun, sunucu yedek davranışını tanımlayın, yeni gereksinimi yayınlayın, istemcileri güncelleyin ve eski ve yeni istek şekilleri için test durumları ekleyin. İstemciler taşındıktan sonra, planlanmış bir kırıcı sürümde zorunlu kuralı uygulayın.

Bir partner belgelenmemiş bir alan değişikliği görür

Bir partner bir yanıt alanını dize olarak ayrıştırır, ancak backend yapılandırılmış bir nesne döndürmek ister. Dahili bir istemci zaten taşınmış olsa bile, partner çalışma zamanında başarısız olabilir.

Sahip ekip partneri bir Katman 1 tüketici olarak kaydeder, eski alanı yerinde değiştirmek yerine bir yenisini ekler, partnere bir test ortamı verir ve kaldırmadan önce kaydedilmiş bir partner işlemini doğrular. Dokümantasyon ve doğrudan iletişim sürüm kanıtının bir parçasıdır.

Tek bir sürüm kontrol listesiyle başlayın

Küçük başlayın. En aktif istemci çalışmasına sahip GraphQL alanını seçin ve bu ay her şema düzenlemesi için bir değişiklik kaydı gerektirin. Değişiklikleri sınıflandırın, temsili işlemleri kaydedin, kullanımdan kaldırmaları belgeleyin ve kaldırmalar için adlandırılmış bir onaylayıcı gerektirin.

Ardından kontrol listesini bir sürüm alışkanlığı haline getirin. Apidog, deponuz yönetişim politikasının kaynağı olarak kalırken istekleri, yanıt doğrulamayı, dokümantasyonu, mock senaryolarını ve test kanıtını bir arada tutabilir. Sonuç, daha az acil geri alma ve her API tüketicisi için daha net beklentilerdir.

SSS

Kırıcı bir GraphQL şema değişikliği neyi kapsar?

Bir değişiklik, sürümden önce geçerli olan bir istemci işlemi sonrasında başarısız olabiliyorsa kırıcıdır. Bir alanı veya argümanı kaldırmak açık bir örnektir. Daha önce isteğe bağlı olan bir girdiyi zorunlu hale getirmek, bir uyumluluk değerlendirmesi olmadan bir tipi değiştirmek, bir enum değerini kaldırmak veya alan davranışını değiştirmek de istemcileri bozabilir.

Bir GraphQL alanı eklemek her zaman güvenli midir?

Genellikle, isteğe bağlı bir alan eklemek mevcut işlemleri geçersiz kılmaz. Yine de beklenmeyen yanıt özelliklerini katı bir şekilde reddeden istemcileri, üretilmiş kodu, dokümantasyon iş akışlarını veya şema araçlarını etkileyebilir. Eklemeyi sınıflandırın, belgeleyin ve katı doğrulama kullanan tüketicileri test edin.

Bir GraphQL alanı ne kadar süre kullanımdan kaldırılmış olarak kalmalıdır?

Pencereyi istemci sürüm döngülerinden, destek taahhütlerinden ve tüketici riskinden belirleyin. Yavaş benimsenen bir mobil uygulama, günlük olarak dağıtılan bir dahili servisten daha fazla zamana ihtiyaç duyar. Son tarihi yayınlayın, kritik tüketicileri belirleyin ve alanı yalnızca geçiş kanıtı tamamlandıktan sonra kaldırın.

GraphQL introspection dokümantasyonun yerini alabilir mi?

Hayır. Introspection araçların bir şemayı keşfetmesine yardımcı olur, ancak net açıklamaların, örneklerin, yetkilendirme notlarının, değişiklik günlüklerinin ve geçiş rehberliğinin yerini almaz. Harici veya kilitli ortamlar introspection'ı da kısıtlayabilir, bu nedenle yayımlanan referans materyallerinin sözleşmeyi kendi başına açıklaması gerekir.

GraphQL kırıcı değişikliklerini üretimden önce nasıl test edersiniz?

Bir şema farkı çalıştırın, ardından aday ortama karşı kaydedilmiş temsili sorguları ve mutasyonları yürütün. GraphQL hatalarını, gerekli verileri, tipleri, enum değerlerini, null davranışını, izinleri ve iş sonuçlarını doğrulayın. Yalnızca genel duman testleri yerine yüksek etkili istemci işlemlerini dahil edin.

Yanıt doğrulaması her GraphQL regresyonunu yakalar mı?

Hayır. Doğrulamayı seçtiğiniz belgelenmiş yanıt sözleşmesini yakalar. Her tüketiciyi tanımlamaz, tam GraphQL şemalarını karşılaştırmaz veya tek başına belgelenmemiş davranış değişikliklerini tespit etmez. Yanıt doğrulamasını işlem testleri, şema incelemesi, sahiplik ve bir kullanımdan kaldırma süreciyle eşleştirin.