GraphQL API Hosting: REST’ten farklar ve net gereksinimler

GraphQL API’ler, REST’e kıyasla istemcinin ihtiyaç duyduğu alanları tek istek içinde seçmesine imkân verir. Bu esneklik doğru tasarlanmazsa performans dalgalanması, bellek/CPU maliyet artışı ve güvenlik açıklarına kapı aralayabilir. Bu yazıda GraphQL API’yi host ederken hangi mimari kararların kritik olduğunu; REST’ten ayrışan noktalarda net kontrol listesi ve uygulanabilir önerilerle anlatıyorum.

GraphQL ve REST: Hosting etkileyen temel farklar

REST’te genellikle sabit kaynaklar (endpoint) ve daha öngörülebilir yanıt şekilleri vardır. GraphQL’te ise tek endpoint (çoğu kurulumda /graphql) üzerinden, sorgu (query) ve mutasyonlar (mutation) ile yanıtın içeriği istenir. Hosting tarafında farkı oluşturan kritik sonuçlar şunlardır:

Sorgu maliyeti istemci tarafından belirlenir. Aynı endpoint’e gelen iki request, alan sayısı/derinlik nedeniyle çok farklı CPU süreleri tüketebilir.
Yanıt boyutu kontrolü REST’e göre daha “dinamik”tir. İstemci, tek sorguda geniş veri çekebilir.
Cache stratejisi REST’te daha doğrudan, GraphQL’te daha karmaşık olabilir. HTTP cache bazen devre dışı kalır; uygulama içi cache (resolver bazlı) daha anlamlıdır.
Güvenlik tarafında “query depth/complexity” kontrolü şarttır. DoS (denial of service) riskini azaltmek için GraphQL’e özel kurallar gerekir.

Hosting kararını belirleyen 3 teknik metrik

GraphQL için “hangi altyapı” sorusunun cevabını metrikler netleştirir: 1. P95/P99 yanıt süresi: Tekil ortalamadan ziyade uzun kuyruklar belirleyicidir. 2. CPU süresi ve GC (garbage collection) davranışı: Özellikle Node.js/Java tarafında query çözümleme sırasında. 3. Arka plan veri erişim maliyeti: Database sorguları ve N+1 (çoklu sorgu) riskleri.

GraphQL cache stratejisi: REST’teki varsayımlar neden yetmeyebilir?

REST’te genellikle GET endpoint’leri kaynak bazlı düşünülür ve ETag, Last-Modified, CDN cache gibi yaklaşımlar daha “doğal” çalışır. GraphQL’te ise istek gövdesi içinde query bulunur; aynı endpoint’e farklı sorgular gelir. Bu yüzden cache’te “net plan” şart.

Uygulanabilir cache katmanları

GraphQL host ederken en sık kullanılan katmanlar:

HTTP/CDN cache (genel amaç): Tek endpoint’te çoğu senaryoda sınırlı fayda sağlar. İstemci query’yi değiştirdikçe varyasyon artar.
Query hash / persist edilecek query (kalıcı sorgu): Aynı sorgu setleri için cache anahtarı üretmek kolaylaşır.
Resolver bazlı cache: Örneğin user(id: ...) resolver’ında 1-5 dk arası TTL ile veri tekrarını azaltmak sık bir çözümdür.
DataLoader ile batch + dedup: Aynı istekte tekrarlayan sorguları birleştirir, N+1’i ciddi biçimde azaltır.

Net cache kontrol tablosu

Aşağıdaki karar tablosu, “restte yaptım, graphql’de neden çalışmadı” sorusunu azaltır:

Gereksinim	REST’te genelde	GraphQL’te daha net yaklaşım
Aynı kaynağın sık çağrılması	CDN/HTTP cache	Resolver cache + TTL + doğru anahtar
Çok sayıda alt alan	Sabit response	Query complexity kontrolü + N+1 azaltım
Cevap varyasyonları	Endpoint bazlı	Query hash/persisted query
Cache invalidation	Kaynak güncellemeyle	Mutation sonrası hedef alanları temizleme

Query maliyetini kontrol etmeden hosting seçimi “tahmin” olur

GraphQL host ederken altyapıyı büyütmek tek başına çözüm değildir. Çünkü aynı sunucu, “karmaşık sorgu” ile aniden çökebilir. Bu yüzden iki net kontrol gerekir: query depth ve query complexity (maliyet).

Depth (derinlik) neden kritik?

GraphQL şeması iç içe alanlar barındırıyorsa (ör. user -> posts -> comments -> ...) istemci aşırı derin sorgu gönderebilir. Depth kısıtı, resolver zincirini sınırlar.

Complexity (maliyet) nasıl ölçülür?

Complexity, alan başına bir ağırlık sistemiyle hesaplanır. Örneğin user 1, posts 3, comments 5 gibi. Böylece toplam maliyet üst limitini aşan sorgular reddedilir.

Net “limit” önerileri

Tek bir sayı herkese uymaz; ancak production için net başlangıç değerleri: - Depth limit: 7–10 - Complexity limit: Uygulamanın resolver maliyetine göre 100–300 aralığı (ilk ölçümle ayarlayın) - Timeout: Resolver/overall request için 2–5 saniye (ihtiyaca göre)

Not: Bu limitleri belirlemenin yolu ölçümdür. İlk etapta log tutup en pahalı sorguları raporlayın, sonra limitleri gerçek dağılıma göre ayarlayın.

Güvenlik: GraphQL’de yetkilendirme ve DoS önlemleri

GraphQL’de tek endpoint üzerinden her şey döndüğü için auth ve rate limit katmanları özellikle önem kazanır.

Yetkilendirmeyi nerede uygulamalısınız?

En net yaklaşım: - Resolver seviyesinde authorization: Alan bazlı izin kontrolü yapılır. - Sadece tek bir “endpoint guard” ile yetinilmez; çünkü sorgu içinde farklı field’lar farklı yetki gerektirebilir.

Rate limit ve throttling

GraphQL için rate limit’i sadece IP bazlı düşünmeyin. Net strateji: - Kullanıcı/token bazlı limit (ör. JWT sub claim) - Geçişe göre (burst) limit: kısa süreli anlık dalgalara tolerans - Persisted query kullanılıyorsa: sorgu bazlı daha hedefli throttling

Büyük risk: N+1 ve veri erişim patlaması

GraphQL resolver’ları doğru tasarlanmadığında veritabanı çağrıları katlanarak artar. Net hedef: - DataLoader ile batch + dedup - İlişkili veriler için join/eager loading (ORM yaklaşımına göre) - Şema ve sorgu örüntüleri üzerinden “en pahalı resolver”ları tespit

Ölçekleme ve barındırma (hosting) mimarisi: REST’ten farklı nereye dikkat?

GraphQL host ederken ölçekleme, “request sayısı” kadar “request başına iş yükü” ile ilgilidir. Bu nedenle sunucu seçimini sadece bant genişliğine bağlamayın.

Statics vs dynamic: Hangi bileşenler nereye koyulur?

GraphQL API katmanı (application server): CPU ağırlıklı olabilir; concurrency önem kazanır.
Database: Resolver’ların ürettiği sorgular belirleyicidir.
Cache (Redis/memory): Sık tekrar eden veriler için etkili.
Queue (background jobs): Webhook/async işlerde yanıt süresini sabitlemek için.

Net mimari örnekleri

Tek instance + yatay ölçek: Read yoğun ve sorgu maliyetleri limitliyse uygundur.
İki katmanlı yaklaşım: API instance’ları stateless; cache ve veritabanı ayrı ölçeklenir.
Async mutasyonlar: Uzun süren işlemleri request-yanıt döngüsünden çıkarın.

Doğru altyapı seçimi: VDS/VPS mi, container mı, dedicated mı?

Bu bölümde “genel öneri” yok; karar noktalarını netleştiriyorum.

VDS/VPS/Dedicated karar matrisi

Aşağıdaki kriterler GraphQL’de daha kritik:

Resolver maliyeti yüksek mi? (karmaşık query, zengin ilişkiler)
P95/P99 hedefiniz ne? (ör. < 300 ms gibi)
Aynı anda kaç aktif kullanıcı? (concurrent)
CPU-bound mı yoksa I/O-bound mı? (DB/cache çağrıları)

Senaryo	Net tercih
Orta trafik, iyi optimize edilmiş şema ve limitler var	VPS/VDS + autoscale iyi başlangıç
P95 düzenli olarak yükseliyor, CPU time artıyor	Daha güçlü instance + cache + query limit
Çoklu tenant veya yüksek eşzamanlılık	Container/Kubernetes veya daha güçlü dedicated
Kritik SLA, kısa kesinti kabul edilmiyor	Dedicated + izleme + yedekli mimari

Container ve process sayısı: concurrency’yi doğru kurma

GraphQL uygulaması tek process ile çalışıyorsa, karmaşık sorgu kuyruğu oluşur. Net yaklaşım: - Uygulama server’da worker/process sayısını CPU çekirdeğine göre belirleyin. - Reverse proxy (NGINX/HAProxy) ile request buffering ve timeout’ları uyumlayın.

İzleme ve loglama: GraphQL’de “ne bozuldu?” sorusunu net yanıtlamak

GraphQL’te performans sorunları genellikle “tek endpoint” altında görünür. Bu yüzden izleme metriklerini sorgu bazında anlamlandırın.

Minimum ölçmeniz gerekenler

request latency histogram (P50/P95/P99)
resolver süreleri (özellikle en pahalı 10 alan)
error rate (özellikle complexity/depth red oranı)
DB sorgu süresi ve en pahalı query’ler
cache hit rate (Redis vb.)

Log şablonu için net öneri

Her isteğe bir request id ekleyin. Sonra loglarda şunlar olsun: - operationName - queryHash (veya persisted query id) - clientId/userId (gerektiğinde maskeleyin) - complexityScore ve depth - toplam süre ve hata tipi

Bu sayede “hangi sorgu” performansı bozduğunu net görürsünüz.

Yedekleme ve veri güvenliği: GraphQL API’nin veri katmanı için net plan

GraphQL API’nin kendisi kadar bağlı olduğu veri katmanları önemlidir. Hosting seçimi kadar yedekleme yaklaşımı da belirleyicidir.

Database yedekleme: günlük snapshot + gerektiğinde PITR (point-in-time recovery) hedefleyin.
Uygulama konfigürasyonu: environment (ENV) değerleri ve secret’lar yedeklenmeli; ancak secret’ları şifreli saklayın.
Schema değişiklikleri: Migration planı (geri dönüş senaryosu dâhil) olmalı.

Sonuç: GraphQL host etmeden önce 6 net kontrol

GraphQL API, REST’e göre daha fazla esneklik sağlar; fakat bu esneklik doğru limitler ve doğru izleme ile yönetilmediğinde performans riskini büyütür. Bu nedenle aksiyonu hemen somutlaştırıyorum:

GraphQL için depth ve complexity limitlerini ilk gün devreye alın.
Cache’i yalnızca HTTP/CDN’e bırakmayın; resolver bazlı cache + DataLoader uygulayın.
Mutasyonları uzun süren işlerden ayırın; arka plan işlerini queue ile yönetin.
Hosting kapasitesini seçerken P95/P99 ve CPU time verisini temel alın.
Loglarda operationName, queryHash, complexityScore, resolver süreleri tutun.
DB yedekleme ve migration geri dönüş planını yazılı hale getirin.

Bu adımlar tamamlandığında, GraphQL’in esnekliğini kaybetmeden REST’teki “öngörülebilirlik” sorununu kontrol altına alırsınız. Sonraki adım olarak NetKıyas’ta hedef trafik/iş yükü senaryonuza göre VDS/VPS veya dedicated seçeneklerini karşılaştırın; karar verirken mutlaka complexity/timeout limitleri ve izleme metrikleriyle birlikte değerlendirin.