Bir geliştirici, dahili bir araçta REST API'yi tRPC ile değiştirmek için iki hafta harcadı.

Bu değişikliğin önemi neden büyüktü

Eski teknoloji yığını; bir DTO, bir doğrulayıcı (validator) ve frontend için ayrı bir TypeScript türleri seti tutmamızı zorunlu kılıyordu. Bir backend alanını yeniden adlandırdığınızda, API hâlâ 200 döndürüyor, UI render edilmeye devam ediyor ve hata yalnızca "undefined" değerleri olarak ortaya çıkıyordu. Sorunu ekipten önce bir müşteri fark etti. REST sözleşmeleri (contracts) problemi gizliyor ve fazladan dosyalar, karşılığını asla vermeyen bir bakım yükü getiriyordu.

REST kurulumu nasıldı

  • OpenAPI spec – uç noktaları (endpoints) tanımlayan ancak asla tek gerçeklik kaynağı (source of truth) olarak hizmet etmeyen statik bir dosya.
  • Client SDK oluşturma adımı – bir JavaScript sarmalayıcısı (wrapper) üreten bir CI işi.
  • Postman koleksiyonu – hiç kimsenin kullanmadığı, paylaşılan bir test aracı.
  • Manuel TypeScript arayüzleri (interfaces) – sunucuyla senkronize kalması gereken, elle yazılmış türler.

Her API değişikliği, doğrulayıcı ve sonraki tüm fetch çağrılarının yanı sıra bu araçlardan en az üçüne dokunuyordu. Süreç hataya açık ve yavaştı.

tRPC kod tabanını nasıl sadeleştirdi

tRPC, ayrı sözleşme dosyasını ortadan kaldırır. Sunucu bir router türü dışa aktarır; istemci aynı türü içe aktarır. Bir backend alanını yeniden adlandırdığınızda, editör uyumsuzluğu anında işaretler; kod çalıştırmaya veya başarısız bir isteğe gerek kalmaz. Geliştirici şunları çıkardı:

  • OpenAPI spec dosyası.
  • Client SDK oluşturma adımı.
  • Kullanılmayan Postman koleksiyonu.
  • Manuel TypeScript arayüzlerinin bulunduğu klasör.

Repo daha yalın hale geldi ve geri bildirimler dağıtım (deployment) sonrasında değil, geliştirme sırasında geldi.

tRPC'nin sınırları

tRPC yalnızca her iki uç da TypeScript konuştuğunda çalışır. Şu durumlarda yetersiz kalır:

  • Bir mobil ekibi Swift veya Kotlin kullanıyorsa.
  • API, harici ortaklar tarafından tüketilecekse.
  • Dilden bağımsız (language-agnostic), halka açık bir arayüze ihtiyacınız varsa.

Geçiş aslında neleri gerektirdi

İki haftalık çaba, kopyala-yapıştır yapmaktan çok daha fazlasıydı. Geliştiricinin şunları yapması gerekiyordu:

  • Her fetch çağrısını tRPC'nin istemci fonksiyonlarını kullanacak şekilde yeniden yazmak.
  • Hata yönetimi (error-handling) mantığını ayarlamak.
  • Ham HTTP yanıtlarına bağlı yükleme (loading) ve yeniden deneme (retry) durumlarına dayanan UI bileşenlerini güncellemek.

Geçiş yapmadan önce sorulması gereken sorular

  • Hem frontend hem de backend TypeScript mi kullanıyor? Paylaşılan bir tür sistemi olmadan tRPC ana avantajını kaybeder.
  • Her iki taraftan da aynı ekip mi sorumlu? Sahiplik boşlukları, sözleşme sapmalarını (contract drift) yeniden tetikleyebilir.
  • Somut bir hatayı mı düzeltiyorsunuz yoksa bir trendin peşinden mi gidiyorsunuz? Verimlilik artışı gerçektir, ancak mevcut bir sorunu (pain point) çözmelidir.

2025 için hibrit bir yaklaşım

Birçok ekip, her iki teknoloji yığınını da çalıştırarak ideal dengeyi buluyor:

  • Dahili uygulama katmanları için tRPC: Kod tabanının tamamen TypeScript olduğu ve sunucu ile istemcinin aynı ekip tarafından yönetildiği durumlar için.
  • Webhook'lar, halka açık API'ler ve ortak entegrasyonları için REST: Dilden bağımsız erişimin gerekli olduğu durumlar için.

Her yüzey için doğru aracı kullanmak, harici tüketiciler için gereken açıklığı korurken dahili geliştirmeyi hızlı tutar.

Özet: REST'i tRPC ile değiştirmek, yinelenen sözleşme araçlarını ortadan kaldırabilir ve hataları düzenleme sırasında ortaya çıkarabilir; ancak kazanımlar, yalnızca tüm yığın TypeScript paylaştığında ve ekip geçiş maliyetini karşılayabildiğinde gerçekleşir. Karma bir strateji, TypeScript kullanmayan tüketicileri dışarıda bırakmadan avantajlardan yararlanmanızı sağlar.