Konuyu Açan
#1
GraphQL ile çalışan bir API tasarlarken sık karşılaşılan bir karışıklık, GraphQL’in veritabanı sorgulama dili sanılması. Oysa SQL, ilişkisel veritabanında veriyi seçmek, birleştirmek ve değiştirmek için kullanılır; GraphQL ise istemcinin hangi alanları istediğini tarif ettiği bir API sorgu dilidir. İki katman çoğu uygulamada resolver’lar aracılığıyla buluşur.
Örneğin bir istemci, kullanıcıyla birlikte o kullanıcının siparişlerini ve her siparişin ürünlerini isteyebilir. GraphQL bu isteği tek bir sorgu olarak ifade edebilir; fakat sunucu bunu otomatik biçimde tek ve verimli bir SQL sorgusuna dönüştürmez. Resolver’lar her ilişki için ayrı sorgu çalıştırırsa N+1 sorunu ortaya çıkar: kullanıcılar için bir sorguya ek olarak her kullanıcı ya da sipariş için yeni sorgular yapılır. İlişkisel veritabanlarında uygun JOIN’ler, toplu yükleme (batching) ve sorgu planlarının incelenmesi bu maliyeti azaltmaya yardımcı olur.
Şema tasarımı da önemlidir. GraphQL tipleri, veritabanı tablolarının bire bir kopyası olmak zorunda değildir; API’nin ihtiyaçlarına göre şekillendirilebilir. Böylece iç veri modeli değişirken istemci sözleşmesini korumak mümkün olur. Ancak yetkilendirme yalnızca GraphQL alanlarını gizlemeye bırakılmamalı; her resolver, kullanıcının istediği kayda erişim hakkını denetlemelidir. Birden fazla tabloyu etkileyen değişikliklerde de işlemler, tutarlılığı korumak için veritabanı transaction’ları içinde yürütülmelidir.
Bu iki katmanı birlikte kullananlarda en çok hangi darboğazı görüyorsunuz: N+1 sorguları, karmaşık şema tasarımı, yoksa yetkilendirme?
Örneğin bir istemci, kullanıcıyla birlikte o kullanıcının siparişlerini ve her siparişin ürünlerini isteyebilir. GraphQL bu isteği tek bir sorgu olarak ifade edebilir; fakat sunucu bunu otomatik biçimde tek ve verimli bir SQL sorgusuna dönüştürmez. Resolver’lar her ilişki için ayrı sorgu çalıştırırsa N+1 sorunu ortaya çıkar: kullanıcılar için bir sorguya ek olarak her kullanıcı ya da sipariş için yeni sorgular yapılır. İlişkisel veritabanlarında uygun JOIN’ler, toplu yükleme (batching) ve sorgu planlarının incelenmesi bu maliyeti azaltmaya yardımcı olur.
Şema tasarımı da önemlidir. GraphQL tipleri, veritabanı tablolarının bire bir kopyası olmak zorunda değildir; API’nin ihtiyaçlarına göre şekillendirilebilir. Böylece iç veri modeli değişirken istemci sözleşmesini korumak mümkün olur. Ancak yetkilendirme yalnızca GraphQL alanlarını gizlemeye bırakılmamalı; her resolver, kullanıcının istediği kayda erişim hakkını denetlemelidir. Birden fazla tabloyu etkileyen değişikliklerde de işlemler, tutarlılığı korumak için veritabanı transaction’ları içinde yürütülmelidir.
Bu iki katmanı birlikte kullananlarda en çok hangi darboğazı görüyorsunuz: N+1 sorguları, karmaşık şema tasarımı, yoksa yetkilendirme?
