Kod öncelikli GraphQL sunucusu
GraphQL şeması, bir GraphQL hizmetinin sözleşmelerini tanımlar; hizmete karşı çalıştırılabilecek türler, alanlar ve mutation kümesini dışa aktarır. Bir GraphQL hizmeti oluştururken şu iki yoldan birini seçebiliriz:
- Şemayı gerçeğin tek kaynağı olarak kabul edip tüm uygulama kodumuzu onun tanımlarına uygun hale getirmek
- Kodumuzu gerçeğin tek kaynağı olarak kabul edip şemayı koddan üretilen bir yapıt olarak oluşturmak
Her iki durumda da tam işlevli bir GraphQL hizmetine sahip oluruz; ancak hangi yaklaşımı kullandığımıza bağlı olarak ilerleyen süreçte daha fazla ya da daha az özelliği, daha kolay ya da daha zor biçimde hayata geçirebiliriz. Bu iki yaklaşım sırasıyla "schema-first" (daha doğru adıyla "SDL-first") ve "code-first" olarak adlandırılır.
Gato GraphQL, kod öncelikli yaklaşımı kullanır. Bunun neden böyle olduğunu inceleyelim.
Gato GraphQL neden code-first kullanır
Code-first yaklaşımında önce resolver'ları kodlarız; ardından kodu tek gerçek kaynağı olarak kullanarak şemayı bir yapıt biçiminde üretiriz. Bu nedenle şema, SDL-first'teki gibi elle oluşturulmak yerine bir komut dosyası çalıştırılarak oluşturulur. Code-first yaklaşımının da bir şeması olduğundan, SDL-first'in sağladığı önemli hiçbir şey eksik kalmaz.
Bununla birlikte, code-first; SDL-first'e kıyasla önemli bir özellik sunar: bağlama göre şeklini ve niteliklerini değiştirebilen dinamik şemalar sağlama ve bunları çalışma zamanında kod aracılığıyla düzenleme imkânı. Gerçekten de Gato GraphQL'in sunduğu tüm büyük özellikler, code-first yaklaşımını benimsemesinin doğrudan bir sonucudur.
Code-first'in avantajları
Dinamik bir şema, aşağıda listelenen avantajların tamamını ve daha fazlasını sağlar:
Şemanın gerçek kaynağı, GraphQL'in gerektirdiğinin bir üst kümesidir. Ek özellikler (global alanlar, global bağlantılar, global direktifler ve kalıcı parçacıklar gibi) GraphQL spesifikasyonuna eklenmesi beklenmeksizin API'mizde zaten kullanılabilir.
Gerçek kaynağı şemaya bağlı olmadığından, başka herhangi bir sistem için de şema üretilebilir: GraphQL yalnızca hedeflerden biridir. Örneğin, aynı gerçek kaynağından bir REST hizmeti için JSON şeması üretilebilir.
API, kullanıcının oturum açıp açmadığına ve oturum açmış kullanıcının rollerine bağlı olarak ya da kullanıcının PRO üyeliği için ödeme yapıp yapmadığı gibi başka bir özelliğe bağlı olarak eş zamanlı hem genel hem özel olabilir ya da daha fazla veya daha az alan sunabilir.
Türler, hangi alanları çözeceklerini önceden bilmez. Bunun yerine, alan resolver'ları yayımla-abone ol deseni kullanarak tür resolver'larına kendilerini bağlar ve alan resolver'ları diğer alan resolver'larını geçersiz kılabilir. Bu özellik, API'yi son derece genişletilebilir kılar; genel bir API kodu oluşturmamıza ve bunu belirli bir istemci veya proje için uygulama düzeyinde özelleştirmemize olanak tanır.
Bir alan yalnızca tek bir resolver tarafından değil, birçok alan resolver'ı tarafından işlenebilir: zincirdeki her alan resolver'ı, çalışma zamanında bir özelliğe göre alanı işleyip işlemeyeceğine karar verebilir ya da onu zincir boyunca iletebilir. Örneğin, özel bir alan resolver'ı yalnızca "source: testing" alan argümanı geçirildiğinde kullanılabilir; bu sayede genel yayından önce üretimde birkaç sitede test edilmesine olanak tanır; aynı strateji, beklenmedik yan etkilere yol açma riski olmaksızın belirli bir istemci veya ortam için hızlı hata düzeltmeleri sağlamayı da mümkün kılar.
Türler ve arayüzler, üçüncü taraflardan gelen çakışmaları önlemek amacıyla otomatik olarak ad alanına alınabilir.