Birden fazla özel endpoint için kullanım durumları
GraphQL'in veriyi sorgulamak için tek bir endpoint açığa çıkarması beklenir. Ancak, her birinin özelleştirilmiş bir şema sunduğu birden fazla özel endpoint'i açığa çıkarmanın daha mantıklı olduğu durumlar vardır. Bu yaklaşım, yalnızca erişilen endpoint'i değiştirerek farklı kullanıcılar veya uygulamalar için farklı davranışlar sunmamıza olanak tanır.
GraphQL'de birden fazla endpoint açığa çıkarmak, REST'e eşdeğer değildir. REST'te her endpoint önceden tanımlanmış bir kaynağa veya kaynak kümesine erişim sağlarken, birden fazla GraphQL endpoint'inin her biri yine de şemasındaki tüm verilere erişim sağlayarak tam olarak ihtiyacımız olanı almamıza olanak tanır. Dolayısıyla bu, farklı şemalardan verilere erişebilme eklentisiyle birlikte normal GraphQL davranışıdır.
Bu yetenek ayrıca, birden fazla veri kaynağını tek bir birleşik grafiğe dahil etmeyi sağlayan şema birleştirme (schema stitching) veya federation'dan da farklıdır. Birden fazla endpoint ile birden fazla şemayla çalışmaktayız. Amaç, bunları daha büyük bir şemanın parçası olarak değil, kendi başlarına ele almaktır.
Farklı şemaların açığa çıkarılması, birden fazla bağımsız grafiğe erişim sağlayabilir. GraphQL'in yaratıcısı Lee Byron, bunun ne zaman yararlı olabileceğini açıklamaktadır:
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
Birden fazla GraphQL endpoint'i açığa çıkarmanın mantıklı olduğu bazı ek kullanım durumlarını inceleyelim.
Admin ve genel endpoint'leri ayrı ayrı açığa çıkarmak
Şirketteki tüm veriler için tek bir grafik kullanırken, erişim kontrol politikaları kurarak GraphQL şemamızdaki farklı alanlara kimin erişebileceğini doğrulayabiliriz. Örneğin, alanları yalnızca giriş yapmış kullanıcılar veya belirli bir role sahip kullanıcılar tarafından erişilebilir olacak şekilde yapılandırabiliriz.
Ancak, hassas veya gizli bilgiler içeren alanlar olduğunda ve bunların hiçbir koşulda yetkisiz kişiler tarafından erişilememesi gerektiğinde, bu alanları genel bir şemada hiç açığa çıkarmamayı, yalnızca ekibin erişebildiği özel bir şemada tutmayı tercih ederiz. Bu strateji, özel verilerimizi yazılım hataları ve şema yapılandırılırken yapılan dikkatsizlikler gibi kasıtsız sorunlardan korur ve hatta özel endpoint'e yalnızca belirli IP'lerden gelen ziyaretçilerin erişmesine izin vererek güvenliği daha da sıkılaştırır.
Bu nedenle, Admin ve Genel şemalar olmak üzere iki ayrı şema oluşturabilir ve bunları sırasıyla /graphql/admin (ve bu endpoint'e erişimi belirli bir IP'den gelen ziyaretçilerle kısıtlayabiliriz) ve /graphql/public (herkese açık) endpoint'leri altında açığa çıkarabiliriz.
Özel bilgilere erişimi daha güvenli bir şekilde kısıtlamak
Bu bölüm, öncekinin genellemesidir: yalnızca genel ile admin karşılaştırması değil, bir kullanıcı grubunun kesinlikle başka bir kullanıcı grubunun bilgilerine erişememesi gereken herhangi bir durum söz konusudur.
Örneğin, farklı müşterilerimiz için özelleştirilmiş şemalar oluşturmamız gerektiğinde, her biri için özel bir endpoint açığa çıkarabiliriz (/graphql/some-client, /graphql/another-client, vb.); bu, onlara aynı birleşik şemaya erişim vermek ve erişim kontrolü aracılığıyla doğrulamaktan daha güvenli olabilir.
Farklı uygulamalara farklı davranış sunmak
Aynı veri kaynağına erişen farklı uygulamalara farklı bir davranış sağlayabiliriz.
Örneğin, Reddit, masaüstü tarayıcıdan veya mobil tarayıcıdan erişilmesine bağlı olarak farklı bir yanıt üretir. Masaüstü tarayıcıdan, oturum açmış olsak da olmasak da içeriği doğrudan görüntüleyebiliriz:
Ancak mobil üzerinden erişirken içeriğe ulaşmak için oturum açmış olmamız gerekir ve uygulamayı kullanmaya teşvik edildiğimiz görülür:
Bu farklı davranış, Masaüstü ve Mobil şemalar olmak üzere iki şema oluşturarak ve bunları sırasıyla /graphql/desktop ve /graphql/mobile altında açığa çıkararak sağlanabilir.
Siteyi farklı dillerde üretmek
Aynı siteyi farklı dillerde üretmek istiyorsak, dil kodunu özel endpoint yapısının bir parçası hâline getirebiliriz; İngilizce için /graphql/en ve Fransızca için /graphql/fr gibi. Ardından, GraphQL sunucusu bu bilgiyi alarak verileri istenen dile çevirebilir.
Son olarak, siteyi bir ya da başka bir dilde üretmek için statik site oluşturucusunda bu endpoint'lerin her birine işaret ederiz:
Yükseltilmiş bir şemayı üretime almadan önce test etmek
GraphQL şemamızı yükseltmek ve bir kullanıcı grubunun bunu önceden test etmesini sağlamak istiyorsak, bu yeni şemayı /graphql/upcoming endpoint'i aracılığıyla açığa çıkarabiliriz. Üstelik, DEV'deki şemayı dağıtmaya devam eden bir /graphql/bleeding-edge endpoint'i de açığa çıkarabiliriz.
BfF yaklaşımını desteklemek
Backend-for-Frontends (kısaca BfF), her istemcinin kendi API'sine "sahip" olmasını sağlayan ve kendi gereksinimlerine göre en uygun sürümü üretmesine olanak tanıyan, farklı istemciler için farklı API'ler üretmeye yönelik bir yaklaşımdır.
Bu modelde, özel bir BfF, arka uç hizmetleri ile istemcisi arasındaki aracıdır:
Bu model, GraphQL'de tüm BfF'lerin birden fazla endpoint'e sahip tek bir GraphQL sunucusunda uygulanmasıyla karşılanabilir; her endpoint belirli bir BfF/istemciyi ele alır (örneğin /graphql/mobile ve /graphql/web):
