GraphQL mi REST mi? Doğru API Yaklaşımını Seçmek

API yaklaşımı, bir uygulamada geri dönmesi en pahalı kararlardan biridir. GraphQL ile REST arasındaki tartışma, uygulamalar ve istemci sayısı büyüdükçe daha sık gündeme geliyor. Cevap nadiren tek kelimelik; bu yazı kararı verirken bakılacak ölçütleri sıralıyor.

Temel kavramlar

REST

REST, kaynakları adreslerle, işlemleri HTTP yöntemleriyle ifade eder:

GET  /api/users/123
GET  /api/users/123/posts
POST /api/users/123/posts

Her uç bir kaynağı temsil eder; GET, POST, PUT, DELETE ne yapılacağını söyler. Anlaşılması kolay, araç desteği çok geniş ve HTTP’nin önbellek, durum kodu gibi özelliklerinden doğrudan yararlanır.

GraphQL

GraphQL, istemcinin ihtiyaç duyduğu veriyi tek bir uca yazdığı sorguyla istediği bir sorgu dilidir:

query {
  user(id: 123) {
    name
    email
    posts(first: 10) {
      title
      comments(first: 5) { text }
    }
  }
}

Bu sorgu kullanıcıyı, son yazılarını ve yorumlarını tek istekte getirir, fazlasını değil.

Temel farklar

Veri çekme

REST: bir ekran birden fazla kaynağa ihtiyaç duyuyorsa istemci birden fazla istek yapar. Mobilde yavaş ağda bu gidiş-gelişler hissedilir.

GraphQL: tek istek, ekranın ihtiyacı kadar veri. Ama yük sunucuya kayar: kötü yazılmış bir çözücü (resolver), yazı başına ayrı veritabanı sorgusu atarak N+1 sorununu sunucu tarafında üretir. Bunu toplu yükleme (DataLoader kalıbı) ile çözmek gerekir.

Fazla ve eksik veri

REST: uçlar sabit yapı döner; yalnız adı gereken istemci tüm kullanıcı alanlarını alır (fazla veri), bir uç ekranın tüm ihtiyacını karşılamaz (eksik veri). Ön yüz için arka uç (BFF) ya da alan seçimi parametreleriyle hafifletilebilir.

GraphQL: istemci alanları kendisi seçtiği için iki sorun da büyük ölçüde ortadan kalkar.

Önbellek

REST: HTTP önbelleği, CDN’ler ve tarayıcı önbelleği doğal olarak çalışır; adres ve yöntem öngörülebilirdir.

GraphQL: istekler çoğunlukla tek bir uca POST ile gittiği için HTTP düzeyinde önbellek zordur. Kalıcı sorgular (persisted queries) ve GET ile gönderim, ya da istemci tarafı normalize önbellek (Apollo, Relay) kullanılır.

Öğrenme eğrisi

REST: kaynak ve HTTP yöntemi kavramı herkesin bildiği bir zemin.

GraphQL: şema tasarımı, çözücüler, sorgu karmaşıklığı ve istemci önbelleği ayrı uzmanlık ister.

Hangisi ne zaman

REST’in güçlü olduğu yerler

Basit CRUD: kayıt oluşturma, okuma, güncelleme, silme ağırlıklı uygulamalar.

Herkese açık API’ler: üçüncü tarafların hızla anlayıp entegre olacağı, uzun süre geriye uyumlu kalması gereken API’ler.

Yoğun önbellek: CDN’den servis edilen, sık okunan içerik.

Dosya ve akış işlemleri: dosya yükleme, indirme ve webhook’lar REST’te daha doğaldır.

GraphQL’in güçlü olduğu yerler

İç içe veri: hesapların, işlemlerin, kartların ve bütçelerin aynı ekranda göründüğü fintech arayüzleri gibi.

Çok sayıda istemci türü: web, mobil ve iş ortağı istemcilerinin farklı veri ihtiyaçları olduğunda.

Hızlı değişen ön yüz: ekran değiştikçe arka uca yeni uç eklemek yerine sorguyu değiştirmek.

Mikroservisleri birleştirmek: birden fazla servisin verisini istemciye tek bir şema olarak sunmak (federation).

Pratikte dikkat edilecekler

Performans ve güvenlik

GraphQL tek istekte çok şey yapabildiği için kötüye kullanıma da açıktır: derin iç içe bir sorgu sunucuyu kilitleyebilir. Sorgu derinlik sınırı, karmaşıklık puanı ve zaman aşımı koyun; üretimde şema keşfini (introspection) kapatmayı ve yalnız kalıcı sorgulara izin vermeyi değerlendirin.

REST’te hız sınırı uç başına kolayca konur. GraphQL’de tek uç olduğu için sınır, istek sayısına değil sorgunun maliyetine göre hesaplanmalıdır.

Yetkilendirme her iki yaklaşımda da sunucuda, alan ve kayıt düzeyinde yapılır; GraphQL’de bir alanın yetki kontrolünü unutmak, o alana ulaşan her sorguyu açar.

Ekip yetkinliği

Ekibiniz REST’te verimliyse ve uygulamanın karmaşıklığı GraphQL’in öğrenme maliyetini haklı çıkarmıyorsa REST doğru seçimdir. Karmaşık ilişkili veri ve birçok istemci varsa GraphQL’e yatırım geri döner.

İzleme

REST’te izleme uç bazındadır ve sezgiseldir. GraphQL’de hemen her istek aynı uca gittiği için izlemeyi sorgu adı (operation name) bazında yapmanız gerekir; isimsiz sorguları reddetmek bu yüzden iyi bir kuraldır.

Karma yaklaşım

Birçok ekip ikisini birlikte kullanır: ön yüze GraphQL, arkada REST ya da gRPC konuşan mikroservisler. Ya da sık okunan, önbelleğe uygun uçlar REST’te kalır, karmaşık ekranlar GraphQL’den beslenir.

Karar için sorular

1. Veri modeliniz ne kadar iç içe? İç içe ilişkiler GraphQL’i öne çıkarır.
2. Kaç farklı istemci türü var? Farklı ihtiyaçları olan çok istemci GraphQL lehine.
3. Ekibinizin deneyimi ne? Mevcut bilgiyi küçümsemeyin.
4. Önbellek ne kadar önemli? CDN’e dayanan içerik REST lehine.
5. API herkese açık mı? Uzun ömürlü, herkese açık API’lerde REST daha öngörülebilir.

Sonuç

GraphQL REST’ten üstün değil, farklı. Basit veri modelli ve sade istemci ihtiyaçlı uygulamalarda REST çoğu zaman doğru seçimdir; birden fazla istemci, iç içe veri ve hızlı değişen ön yüz söz konusuysa GraphQL kendini öder. İhtiyacınızı karşılayan en basit çözümle başlayın; karmaşıklık arttıkça karma yaklaşıma geçmek her zaman mümkün.

API tasarımınızı birlikte değerlendirmek isterseniz bize yazın.