REST mi, GraphQL mi? API Mimarisi Seçimi

REST ve GraphQL aynı işi farklı felsefelerle yapar. Hangisinin projenize uygun olduğunu veri yapısı, ekip ve bakım açısından karşılaştırıyorum.

Rıdvan Ay 5 dk okuma API ve Entegrasyonlar

İçindekiler
  1. Kısaca iki yaklaşım
  2. Aynı ekran, iki farklı yol
  3. REST mi GraphQL mi? Karşılaştırma tablosu
  4. REST’in öne çıktığı durumlar
  5. GraphQL’in avantaj sağladığı durumlar
  6. Karar verirken sormanız gereken sorular
  7. Bu işi nasıl birlikte yaparız?
  8. Sık sorulan sorular
  9. Sonuç

Yeni bir mobil uygulama ya da web platformu planlarken teknik ekipten iki farklı öneri gelebilir: biri REST, diğeri GraphQL der. Karar sizde kaldığında “REST mi GraphQL mi?” sorusu, bir moda tartışmasına dönüşmeden, projenizin gerçek ihtiyaçlarına göre cevaplanmalıdır. Bu yazıda iki yaklaşımın nasıl çalıştığını, hangi durumda hangisinin işinizi kolaylaştırdığını ve seçim yaparken sormanız gereken soruları anlatacağım.

Kısaca iki yaklaşım

REST, her veri türü için ayrı bir adres (uç nokta) tanımlar: ürünler bir adreste, yorumlar başka bir adreste, kullanıcı bilgisi bir başkasında durur. Sunucu, her adreste ne döneceğine kendisi karar verir. Ayrıntılı anlatım için REST API nedir, nasıl tasarlanır yazısına bakabilirsiniz.

GraphQL ise genellikle tek bir adres kullanır. İstemci, ihtiyaç duyduğu alanları bir sorgu diliyle tarif eder ve sunucu tam olarak o alanları döndürür. Facebook tarafından geliştirilip açık kaynak olarak yayımlanmıştır ve bir şema (schema) üzerine kuruludur; şema, hangi verinin hangi tipte sorgulanabileceğini kesin olarak tanımlar.

Aynı ekran, iki farklı yol

Somut bir senaryo düşünelim: Bir restoran uygulamasında ürün detay ekranı açılıyor. Ekranda ürün adı, fiyatı, son üç yorum ve yorumu yazanın adı görünmeli.

REST ile tipik olarak önce ürün bilgisi, ardından yorumlar istenir. Yorum yazanların adları ayrı bir uç noktadaysa bir istek daha gerekir. Üstelik ürün uç noktası, ekranda kullanılmayan onlarca alanı (stok kodu, tedarikçi, oluşturma tarihi) da gönderebilir. Buna fazla veri çekme (over-fetching) ve çoklu istek (under-fetching) sorunu denir.

GraphQL ile tek bir sorgu yazılır:

query {
  product(id: 42) {
    name
    price
    reviews(last: 3) { text author { name } }
  }
}

Sunucu yalnızca bu alanları döndürür. Mobil ağda, özellikle zayıf bağlantıda, bu fark hissedilir olabilir. Ancak aynı sonuç REST’te de ekrana özel bir uç nokta tasarlanarak elde edilebilir; yani fark, imkânsız ile mümkün arasında değil, esneklik ile sadelik arasındadır.

REST mi GraphQL mi? Karşılaştırma tablosu

Ölçüt REST GraphQL
Öğrenme ve kurulum Yaygın, basit, araç desteği çok geniş Şema, çözücü (resolver) ve ek araç bilgisi gerektirir
Veri esnekliği Sunucu ne verirse o; özel ihtiyaç için yeni uç nokta İstemci istediği alanları seçer
Önbellekleme HTTP önbelleği ve CDN ile doğal uyum Tek adres ve POST istekleri nedeniyle ek kurgu gerekir
Hata yönetimi HTTP durum kodlarıyla net Çoğunlukla 200 döner, hata cevabın içinde taşınır
Dosya yükleme Doğrudan desteklenir Ek yaklaşımlar gerekir
Sürümleme Genellikle sürüm numarasıyla Şemaya alan ekleyip eskiyi kullanımdan kaldırarak
Performans riski Gereksiz veri, çok sayıda istek Kontrolsüz derin sorgular sunucuyu yorabilir

REST’in öne çıktığı durumlar

İşletmelerin büyük kısmının ihtiyacı için REST hâlâ en pratik seçimdir. Şu durumlarda REST’i öneriyorum:

  • Veri yapısı görece basitse ve ekranlar benzer veriler kullanıyorsa.
  • Üçüncü taraf firmalar (kargo, ödeme, pazaryeri) API’nizi kullanacaksa; neredeyse herkes REST’e alışkındır.
  • Önbellekleme ve CDN ile yüksek trafik karşılanacaksa. Bu konuyu API önbellekleme yazısında ayrıca ele aldım.
  • Ekip küçükse ve bakımı kolay, sade bir yapı isteniyorsa.
  • Dosya yükleme, webhook ve standart HTTP davranışları yoğun kullanılacaksa.

GraphQL’in avantaj sağladığı durumlar

GraphQL, belirli koşullarda gerçek bir verimlilik sağlar:

  • Web, iOS, Android ve yönetim paneli gibi birçok istemci aynı veriden farklı parçalar istiyorsa.
  • Veri modeli çok ilişkiliyse (kullanıcı, sipariş, ürün, yorum, kampanya iç içe geçiyorsa).
  • Ön yüz ekibi, her yeni ekran için arka uç ekibini beklemeden ilerlemek istiyorsa.
  • Birden fazla iç servisi tek bir sorgu katmanı altında birleştirmek gerekiyorsa.

Bu avantajların bedeli, daha fazla kurulum ve dikkattir. Sorgu derinliği ve karmaşıklığı sınırlanmazsa tek bir kötü niyetli ya da dikkatsiz sorgu sunucuyu zorlayabilir. Yetki kontrollerinin de alan düzeyinde düşünülmesi gerekir.

Karar verirken sormanız gereken sorular

  1. API’yi kimler kullanacak: yalnızca sizin uygulamalarınız mı, dış firmalar da mı?
  2. Kaç farklı istemci (web, mobil, panel) olacak ve ihtiyaçları ne kadar farklı?
  3. Veriler ne kadar ilişkili ve iç içe?
  4. Trafik yüksek mi, önbellekleme kritik mi?
  5. Projeyi ileride devralacak geliştiricileri bulmak ne kadar kolay olacak?

Bu soruları yanıtlarken bir örnek yardımcı olabilir. Tek şubeli bir işletmenin web sitesi ve basit bir mobil uygulaması için REST mi GraphQL mi diye düşündüğümüzde, ekranların ihtiyaçları birbirine çok yakın olduğu için REST genellikle daha az iş ve daha kolay bakım demektir. Öte yandan müşteri uygulaması, kurye uygulaması, şube paneli ve merkez raporlama ekranı olan bir yemek siparişi platformunda her istemci aynı siparişin farklı alanlarını ister; burada GraphQL’in esnekliği geliştirme hızını artırabilir.

Bu soruların cevabına göre bazen ikisi birlikte de kullanılır: dış dünyaya REST, kendi uygulamalarınıza GraphQL. Mobil uygulama arka ucu planlıyorsanız mobil uygulama backend yazısı da karar sürecinize katkı sağlayacaktır.

Bu işi nasıl birlikte yaparız?

API mimarisi seçimi, projenin geri kalanını yıllarca etkiler. Bu kararı birlikte şöyle veriyoruz:

  1. Ekranları ve istemcileri listeleme: Hangi uygulamanın hangi veriyi göstereceğini kabaca çıkarırız.
  2. Mimari öneri ve teklif: REST, GraphQL ya da ikisinin birlikteliği için gerekçeli bir öneri ve kapsamlı bir teklif sunarım.
  3. Prototip ve test: Kritik bir ekranı uçtan uca çalışır hâle getirip hız ve geliştirme kolaylığını gerçek veriyle ölçeriz.
  4. Teslim ve belgeleme: Şemayı veya uç noktaları belgeleyip kaynak koduyla teslim eder, sonrasında destek veririm.

Projenizi değerlendirmek için iletişim sayfasından bana yazabilirsiniz.

Sık sorulan sorular

GraphQL, REST’in yerini mi alıyor?

Hayır. İki yaklaşım farklı ihtiyaçlara cevap verir ve birlikte var olmaya devam ediyor. REST hâlâ en yaygın API tarzıdır.

GraphQL daha mı hızlıdır?

Her zaman değil. Gereksiz veri aktarımını azaltabilir ama sunucu tarafında sorgu çözümleme maliyeti ekler. Hız, tasarıma ve önbellekleme stratejisine bağlıdır.

Mevcut REST API’mi GraphQL’e taşımam gerekir mi?

Çalışan bir REST API’yi yalnızca moda olduğu için taşımak gerekmez. Somut bir sorun (çok fazla istek, istemci ihtiyaçlarının çok farklılaşması) varsa mevcut API’nin önüne bir GraphQL katmanı eklemek de bir seçenektir.

WordPress ile GraphQL kullanılabilir mi?

Evet, eklentilerle mümkündür. Ancak WordPress zaten yerleşik bir REST API sunduğu için çoğu proje ek bir katmana ihtiyaç duymaz.

Sonuç

REST mi GraphQL mi sorusunun herkes için tek bir cevabı yok. Sade, dış dünyaya açık ve önbelleklemenin önemli olduğu projelerde REST; çok istemcili ve ilişkisel verinin yoğun olduğu projelerde GraphQL öne çıkar. Projenize uygun mimariyi birlikte seçmek isterseniz bana ulaşabilirsiniz.

İlgili yazılar