GraphQL Nedir? API'ler İçin Sorgu Dili

GraphQL, API'ler için geliştirilmiş bir sorgu dili ve bu sorguları çalıştıran bir sunucu tarafı çalışma zamanıdır. 2012'de Facebook içinde geliştirilmiş, 2015'te açık kaynak olarak yayınlanmış ve bugün bağımsız GraphQL Vakfı tarafından yönetiliyor. Temel vaadi basittir: İstemci, sunucudan tam olarak ihtiyaç duyduğu veriyi, tek bir istekte alabilsin — ne eksik ne fazla.

GraphQL'i anlamanın en kolay yolu, çözmeye çalıştığı sorunu geleneksel REST API'lerle karşılaştırmaktır.

REST'in iki klasik sorunu

REST API'lerde her kaynak genellikle sabit bir adrese (endpoint) sahiptir ve her adres önceden belirlenmiş bir veri yapısı döner. Bu, iki yaygın verimsizliğe yol açar:

• Aşırı veri çekme (over-fetching): Sadece bir kullanıcının adını istiyorsunuz, ama /users/1 adresi adres, telefon, sipariş geçmişi dahil her şeyi döndürüyor. Gereksiz veri hem bant genişliği hem işlem israfıdır.
• Yetersiz veri çekme (under-fetching): Bir ekranı doldurmak için kullanıcıyı, siparişlerini ve her siparişin ürünlerini göstermeniz gerekiyor. Bu, art arda üç ayrı isteğe (/users/1, /users/1/orders, /orders/.../items) dönüşür. Çok sayıda gidip gelme, özellikle mobil ağlarda uygulamayı yavaşlatır.

GraphQL bu iki sorunu da tek bir esnek istekle ortadan kaldırır.

Şema: Sözleşmenin merkezi

Her GraphQL API'sinin merkezinde bir şema (schema) vardır. Şema, API'nin sunduğu tüm veri tiplerini ve bunlar arasındaki ilişkileri güçlü biçimde tiplenmiş olarak tanımlar — bir tür sözleşme. İstemci yalnızca şemada tanımlı alanları sorgulayabilir; bu da hem öngörülebilirlik hem de güçlü araç desteği sağlar. Örneğin bir istemci şunu sorabilir:

• user tipinden yalnızca ad ve email alanlarını,
• aynı istekte o kullanıcının siparisler ilişkisini,
• ve her siparişin yalnızca tarih alanını.

Sunucu da tam olarak bu şekli taşıyan bir JSON döndürür. İstemci isteğin biçimini belirler; sunucu bu biçmi doldurur.

Üç temel işlem türü

GraphQL'de istemci-sunucu etkileşimi üç tür işlemle yürür:

• Query (sorgu): Veri okuma işlemleri. REST'teki GET'in karşılığı.
• Mutation (değişiklik): Veri oluşturma, güncelleme, silme. Yazma işlemleri bu tür altında, açıkça ayrılmış biçimde yapılır.
• Subscription (abonelik): Sunucudaki değişiklikleri gerçek zamanlı olarak istemciye iletmek için kullanılır; canlı güncelleme gerektiren uygulamalarda işe yarar.

Tek adres, resolver'lar

REST'in aksine GraphQL tipik olarak tek bir adres (genellikle /graphql) üzerinden çalışır. Gelen her sorgu bu adrese POST edilir. Sunucu tarafında, sorgudaki her alan bir resolver fonksiyonuyla eşleşir; resolver o alanın verisini nereden (veritabanı, başka bir servis, önbellek) getireceğini bilir. Böylece veri kaynakları istemciden gizlenir ve tek bir sorgu birden fazla kaynaktan derlenebilir.

GraphQL ne zaman doğru seçim, ne zaman değil?

GraphQL her zaman REST'in yerini almaz; bir araçtır, gümüş kurşun değil. Güçlü olduğu yerler:

• Çok sayıda farklı istemcinin (web, mobil, üçüncü taraf) aynı API'den farklı veri şekilleri istediği durumlar.
• Birçok ilişkili kaynağın tek ekranda birleştiği, veri yoğun arayüzler.
• Hızlı değişen ürünlerde, istemcinin sunucuyu değiştirmeden yeni alanlar talep edebilmesi.

Buna karşılık basit, az sayıda kaynağı olan servislerde REST daha az kurulum ve daha az karmaşıklıkla aynı işi görebilir. GraphQL ayrıca önbellekleme ve sorgu karmaşıklığı denetimi gibi konularda ek özen gerektirir.

Nereden başlamalı?

GraphQL'in resmi sitesi, dilin özelliklerini, örnek sorguları ve kavramları adım adım açıklayan interaktif bir öğrenme deneyimi sunar. Pratikte çoğu geliştirici, bir dil için hazır bir GraphQL sunucu kütüphanesi ve istemci tarafında sorguları yöneten bir istemci kütüphanesiyle başlar. Önce şema tasarımını, ardından query/mutation ayrımını ve resolver mantığını kavramak, teknolojinin bütününü oturtmanın en sağlıklı yoludur.