REST API'lerin Devri Kapanıyor mu? Modern Projelerde tRPC ve GraphQL Kullanımı

Web geliştirme dünyasında veri iletişimi denince akla gelen ilk ve en güçlü standart, yıllardır tartışmasız REST (Representational State Transfer) mimarisidir. Kaynak tabanlı yapısı, HTTP metodlarını (GET, POST, PUT, DELETE) kullanması ve basitliği, onu internetin varsayılan dili haline getirdi. Ancak modern web uygulamalarının karmaşıklığı arttıkça, REST'in bazı yapısal sınırları geliştiriciler için yorucu olmaya başladı.

Bugün, "REST öldü mü?" sorusundan ziyade, "Hangi senaryoda hangi araç daha verimli?" sorusunu tartışıyoruz. Sahneye çıkan iki güçlü alternatif, GraphQL ve özellikle TypeScript ekosisteminde fırtınalar estiren tRPC, veri çekme süreçlerini kökten değiştirmeyi vaat ediyor.

REST API'nin Temel Sorunları: Neden Alternatif Aranıyor?

REST, basit CRUD (Yarat, Oku, Güncelle, Sil) işlemleri için harikadır. Ancak kompleks kullanıcı arayüzlerinde (UI) şu iki büyük sorunla sıkça karşılaşırız:

  • Over-fetching (Aşırı Veri Çekme): Bir kullanıcının sadece adını ve profil fotoğrafını göstermek istiyorsunuz ancak /api/users/1 endpoint'i size kullanıcının adresini, fatura bilgilerini ve son 50 siparişini de gönderiyor. Bu, gereksiz bant genişliği ve performans kaybı demektir.
  • Under-fetching ve N+1 Sorunu: Bir gönderiyi ve o gönderiye yapılan yorumları, yorum yapanların profilleriyle birlikte göstermeniz gerekiyor. REST ile bu genellikle 3 farklı API çağrısı (gönderi, yorumlar, kullanıcılar) gerektirir. Bu da istemci tarafında çok fazla ağ isteği ve gecikme yaratır.

GraphQL: İstemcinin Gücü Elinde Tutması

Facebook tarafından bu sorunları çözmek için geliştirilen GraphQL, veri çekme mantığını tamamen tersine çevirir. GraphQL'de birden fazla endpoint yoktur; tek bir /graphql endpoint'i vardır.

Temel Felsefesi: İstemci (Frontend), sunucuya (Backend) bir "sorgu" (query) gönderir ve tam olarak hangi veri alanlarını istediğini belirtir. Sunucu, sadece istenen verileri, tam olarak istenen yapıda döndürür.


// İstemcinin gönderdiği GraphQL Sorgusu
query {
  user(id: "1") {
    name
    profilePicture
    orders(last: 3) {
      id
      totalPrice
    }
  }
}

Avantajları: Over-fetching ve under-fetching sorunlarını tamamen çözer. Güçlü bir şema yapısı (Schema) vardır, bu sayede dokümantasyon otomatiktir. Dezavantajları: Caching (önbellekleme) REST kadar basit değildir. Sunucu tarafında sorgu karmaşıklığını yönetmek (N+1'i çözmek için DataLoader kullanımı vb.) ek bir öğrenme eğrisi gerektirir.

tRPC: TypeScript Ekosisteminde "Tip Güvenli" Devrim

tRPC, "TypeScript Remote Procedure Call" anlamına gelir ve GraphQL'in esnekliğine ihtiyaç duymayan, ancak tamamen TypeScript ile yazılmış tam yığın (full-stack) uygulamalar için muazzam bir verimlilik sunar.

Temel Felsefesi: API şemaları veya dokümantasyonlarla uğraşmanıza gerek yoktur. Backend'de yazdığınız fonksiyonları, Frontend'de sanki yerel bir fonksiyormuş gibi, tam tip güvenliği (end-to-end type safety) ve otomatik tamamlama (autocomplete) ile çağırırsınız.


// Backend (sunucu) tarafı
const userRouter = router({
  getById: publicProcedure
    .input(z.string()) // Tip kontrolü (Zod)
    .query(async (opts) => {
      return await db.user.findUnique({ where: { id: opts.input } });
    }),
});

// Frontend (istemci) tarafı
// Otomatik tamamlama ve tip güvenliği ile çağırma:
const user = trpc.user.getById.useQuery('1'); 
// user.data artık Backend'deki user objesinin tam tipine sahiptir.

Avantajları: İnanılmaz hızlı geliştirme deneyimi. Frontend ve Backend arasında tip uyuşmazlığı hatası alma ihtimalini sıfıra indirir. API dokümantasyonu yazma zorunluluğunu ortadan kaldırır. Dezavantajları: *Sadece* TypeScript projelerinde çalışır. Kamuoyuna açık, üçüncü parti geliştiricilerin kullanacağı API'ler için uygun değildir.

Hangi API Mimarisi Sizin İçin Uygun? (Karar Matriksi)

Devir kapanmıyor, ancak araç çantası zenginleşiyor. İşte modern projeler için bir karar rehberi:

  • Projeyi Sadece Siz mi Yazıyorsunuz (Full-stack TypeScript)?
    👉 Kesinlikle tRPC. En hızlı, en güvenli ve en az "boilerplate" (kalıp kod) gerektiren çözümdür.
  • Karmaşık Veri İlişkileri ve Farklı İstemciler (Web, Mobil, IoT)?
    👉 GraphQL. İstemcilerin kendi veri ihtiyaçlarını kendilerinin belirlemesi, mobil uygulamaların bant genişliğini korur ve Backend'i esnek kılar.
  • Basit CRUD İşlemleri, Kamuoyuna Açık API veya Veteran Ekip?
    👉 REST API hâlâ en güvenli, en yaygın ve en kolay caching yapılan seçenektir. Herkes HTTP bilir.

Modern web mimarisinde artık tek bir doğru yok. Projenizin ihtiyaçlarını, ekibinizin yeteneklerini ve verinin karmaşıklığını analiz ederek en doğru aracı seçmek, gerçek yazılım geliştirme sanatıdır.