Mühendislik ekipleri hâlâ REST'in öldüğü ya da gRPC'nin geri kalan her şeyi geçersiz kıldığı konusunda tartışarak bütün öğleden sonralarını yakıp kül ediyor. Bu tartışma asıl noktayı kaçırıyor. En iyi protokolü seçmiyorsunuz. Doğru sınırı seçiyorsunuz. Kubernetes kümenizin içinde harika çalışan bir protokol, onu binlerce dış geliştiriciye teslim ettiğinizde boğulabilir. Mobil uygulamanız için değerli bant genişliğinden tasarruf sağlayan bir protokol, onu rastgele genel sorgulara açarsanız altyapınızı iflas ettirebilir. Bu kararı bir teknoloji popülerlik yarışması gibi ele alırsanız, ekibinizdeki her mevcut üyeden daha uzun süre yaşayacak bir mimari borç (architectural debt) inşa edersiniz.

Sınır İlkesi

Mimari, şampiyonlar değil, ödünleşimler (trade-offs) hakkındadır. Doğru soru asla "Hangisi en hızlı?" veya "Hangisi en yenisi?" değildir. Soru şudur: "Hattın diğer ucunda kim oturuyor ve neyi kontrol ediyorlar?" Protokoller sınır nesneleridir. Yanlış olanı seçmek sizi sadece yavaşlatmaz; hataları yıllar boyunca sisteminize işler.

Genel API'ler: REST Sıkıcı Değil, Sorumludur

Tüketiciniz hiç tanışmadığınız bir dış geliştirici olduğunda, API'niz yalnızca bir arayüz değil, bir üründür. O geliştirici, gece saat ikide elinde sadece curl ve bir Postman koleksiyonuyla hata ayıklıyor (debugging). Eğer ilk başarılı çağrılarından önce özel bir istemci kütüphanesi kurmaları veya bir şema dili öğrenmeleri gerekiyorsa, onları çoktan kaybetmişsiniz demektir.

REST burada hayatta kalıyor çünkü web'in kendisi o. HTTP metodları, durum kodları ve JSON ortak dildir. Önbelleğe alma (caching) sonradan düşünülmüş bir şey değildir; halihazırda var olan bir altyapıdır. Tarayıcılar, CDN'ler ve uç önbellekler (edge caches), Cache-Control başlıklarını ve ETag doğrulamasını yerel olarak anlar. Bir REST API'yi standart bir CDN'nin arkasına yerleştirebilir ve tek bir satır önbelleğe alma mantığı yazmadan anında bant genişliği tasarrufu sağlayabilirsiniz. Genel trafik öngörülemez olduğunda ve bulutunuzdan çıkan her gigabayt için ödeme yaptığınızda bu çok önemlidir.

Buna karşılık GraphQL, genel bir sınır için ağır bir vergi getirir. Tek bir dikkatsiz veya kötü niyetli sorgunun veritabanınızı çökertmesini önlemek için genel GraphQL uç noktalarının (endpoints) sorgu maliyeti analizi, derinlik sınırlaması ve karmaşıklık puanlamasına ihtiyacı vardır. Sadece bir API sunmuyorsunuz; bir sorgu yürütme motoru, bir hız sınırlama (rate-limiting) stratejisi ve bir hesaplama faturalandırma modeli inşa ediyorsunuz. En büyük platformların operasyonel gücüne sahip değilseniz, bu ek yük genel bir yüzey alanı için pervasızcadır. REST, varsayılan olarak koruma bariyerleri (guardrails) sağlar. Her uç nokta tek bir iş yapar. Tüketiciler, hayal edebilecekleri her şeyi değil, tam olarak sunduğunuz şeyi çekerler.

Dahili Servisler: Tüm Boruyu Siz Yönetin

Organizasyonunuzun içinde konuşma değişir. Hem istemciyi hem de sunucuyu siz kontrol edersiniz. Çağrı zincirindeki her servis için teknoloji yığınını (technology stack) dikte edebilirsiniz. İşte gRPC'nin hakkını verdiği yer burasıdır.

İlk olarak, JSON'u kutsal olarak görmeyi bırakın. Protocol Buffers, JSON'dan yaklaşık üç kat daha hızlı serileştirme yapar. Format ikili (binary) olduğu için veri yükleri (payloads) daha küçüktür. Yoğun bir dahili ağda, bu milisaniyeler ve megabaytlar gerçek paraya ve daha düşük kuyruk gecikmesine (tail latency) dönüşür. Daha da önemlisi, Protobuf size katı bir sözleşme (contract) sunar. Bir alan tipini değiştirdiğinizde veya bir mesajı yeniden adlandırdığınızda, kopma (break) üretim ortamında (production) gece saat üçte bir alt servis ayrıştırma hataları (parse exceptions) fırlatmaya başladığında değil, derleme zamanında (compile time) gerçekleşir.

gRPC, HTTP/2 üzerinden çalışır, bu nedenle başlık sıkıştırma (header compression), çoklanmış akışlar (multiplexed streams) ve gerçek akış semantiği (streaming semantics) elde edersiniz. Servisler arasında yüksek verimli olaylar (high-throughput events) aktarıyorsanız veya gerçek zamanlı güncellemeler gönderiyorsanız, sunucu tarafı ve çift yönlü akış (bidirectional streaming) birer istek-yanıt çerçevesine bantlanmış uzun süreli yoklama (long-polling) geçici çözümleri değil, yerel özelliklerdir.

Zor bir engel var: gRPC'yi doğrudan bir tarayıcıya yönlendirmeyin. Tarayıcı ağ modelleri, HTTP/2'yi gRPC'nin beklediği şekilde konuşmaz. Bir tarayıcının arka uçla (backend) konuşmasını sağlamak için yığınınıza grpc-web ve Envoy gibi bir proxy eklemek zorunda kalırsınız. Bu bir hata değil, bir sınır sinyalidir. gRPC'yi güvenlik duvarınızın arkasında, birbirine güvenen servisler arasında tutun ve hata ayıklama karmaşıklığını hızın bedeli olarak kabul edin. İkili (binary) veri yükleri, JSON'un yaptığı gibi bir günlük dosyasında (log file) kolayca gözle okunamaz.

Karmaşık Kullanıcı Arayüzleri ve Mobil: GraphQL'in Nişi

Modern mobil ekranlar birer yamalı bohçadır. Bir görünüm bir kullanıcı profiline ihtiyaç duyabilir,