1. GİRİŞ

gRPC, Google tarafından geliştirilmiş, yüksek performanslı, açık kaynaklı bir uzak prosedür çağrısı (RPC) framework'üdür. Modern dağıtık sistemlerin ihtiyaç duyduğu düşük gecikme, verimli binary serileştirme, ve güçlü tip sistemi gibi gereksinimleri karşılamak için tasarlanmıştır. Protobuf (Protocol Buffers) ile birlikte kullanılarak hem performans hem de tip güvenliği sağlar. gRPC, mikroservisler arası backend‑to‑backend iletişiminde, gerçek‑zamanlı streaming uygulamalarında ve mobil/edge cihazlarda verimli veri aktarımı gerektiren senaryolarda tercih edilmektedir.

Bu konu neden bugün önemli?

• Hizmetler arası iletişimde yüksek throughput ve düşük latency beklentileri artıyor.
• Streaming ve bidirectional iletişim gereksinimleri (telemetry, realtime messaging) yaygınlaşmakta.
• Polyglot sistemlerde ortak IDL üzerinden tip güvenli contract'lar tanımlamak ekipler arası entegrasyonu kolaylaştırıyor.

Kimler için önemli?

• Yazılım mimarları ve backend mühendisleri
• Platform mühendisleri, SRE ve DevOps ekipleri
• Gerçek zamanlı sistemler, IoT ve yüksek trafikli backend tasarımıyla ilgilenenler

Hangi problemleri çözüyor?

• Düşük gecikmeli, yüksek verimli servis‑ler arası iletişim
• Tip güvenli API sözleşmeleri (service contracts) ve kolay client code generation
• Yerleşik streaming modeller ile gerçek zamanlı veri akışının yönetimi

2. KAVRAMSAL TEMELLER

2.1 gRPC nedir — kısa tanım

gRPC, HTTP/2 taşıyıcı protokolü üzerinde çalışan bir RPC framework'üdür. API tanımları .proto dosyaları (Protocol Buffers) ile yapılır; bu dosyalardan client ve server için veri modelleri ve stub'lar otomatik üretilir. gRPC, binary serileştirme, header compression, multiplexing ve stream control gibi HTTP/2 özelliklerinden faydalanır.

2.2 Protobuf (Protocol Buffers)

Protobuf, gRPC ile sıkça kullanılan bir veri tanımlama ve serileştirme biçimidir. İnsan tarafından okunabilir .proto şemaları ile veri tipleri, mesajlar ve servisler tanımlanır. Protobuf düşük boyutlu binary formatı sayesinde ağ ve CPU üzerindeki maliyeti azaltır. Ayrıca geriye dönük uyumluluk (backward/forward compatibility) için güçlü kurallara sahiptir.

2.3 gRPC çağrı türleri

• Unary: Tek request → tek response. Geleneksel HTTP/REST çağrılarına benzer.
• Server streaming: Tek request → çoklu response. Sunucu istek başına akış gönderir.
• Client streaming: Çoklu request → tek response. İstemci bir stream gönderir, sunucu sonunda cevap verir.
• Bidirectional streaming: Çoklu request ↔ çoklu response. İki taraf birbirine stream ile veri gönderir; eşzamanlıdır ve ordering bağımsız olabilir.

2.4 IDL ve code generation

.proto dosyaları servislerin ve mesaj tiplerinin kesin sözleşmesini belirtir. Bu IDL (Interface Definition Language), polyglot kod üretimi sayesinde Java, C#, Go, Python, Node.js, Rust ve diğer diller için otomatik stub ve model üretimi sağlar. Bu, takımlar arası uyumu ve hızla yeni client üretimini kolaylaştırır.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 HTTP/2 avantajları

gRPC, HTTP/2 üzerinde çalışarak şu avantajları elde eder:

• Multiplexing: Aynı TCP bağlantısı üzerinde paralel RPC çağrıları (stream'ler) çalıştırılabilir; connection head‑of‑line blocking azalır.
• Binary framing ve header compression: Daha az veri transferi ve daha az CPU maliyeti.
• Server push ve stream flow control: Streaming senaryoları verimli yönetilir.

3.2 Protobuf serileştirme ve performans

JSON yerine Protobuf kullanıldığında mesaj boyutu küçülür ve serileştirme/deserileştirme CPU maliyeti azalır. Bu, yüksek QPS (queries per second) gerektiren sistemlerde maliyet ve performans farkı yaratır. Ayrıca Protobuf, alan numaralandırması sayesinde geriye dönük uyumu kolaylaştırır.

3.3 Stub tabanlı iletişim ve contract driven geliştirme

gRPC'de client-side stub'lar ve server-side skeleton'lar .proto'dan üretilir. Bu, contract‑driven development (CDD) yaklaşımını güçlendirir: API değişiklikleri şema düzeyinde yönetilir, otomatik testler ve CI süreçleri ile entegrasyon sağlanır.

3.4 Streaming kullanım örnekleri ve data flow

Streaming, telemetry, canlı metrik, chat, video/audio segmentleri ve büyük veri yüklemeleri gibi senaryolarda yaygındır. Data flow kontrolü HTTP/2'nin flow control mekanizmaları ve gRPC'nin backpressure yaklaşımları ile sağlanır. Bidirectional streaming, low‑latency interaktif uygulamalar için idealdir.

3.5 Error handling ve status codes

gRPC, HTTP durum kodlarından bağımsız olarak kendi status kodları (OK, CANCELLED, UNKNOWN, INVALID_ARGUMENT, DEADLINE_EXCEEDED, etc.) sunar. Bu kodlar, hata türlerini daha net ifade eder. Ayrıca status metadata ile detaylı hata bilgisi ve debug bilgisi taşınabilir.

3.6 Deadlines / Timeouts ve Cancellation

gRPC istemcileri çağrı sırasında deadline belirleyebilir; bu, uzun süren RPC'lerin kaynak tüketmesini engeller. Sunucu tarafı da cancellation signal'lerini alarak kaynakları hızlıca serbest bırakabilir. Bu mekanizmalar, sistem kararlılığı için kritik öneme sahiptir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Google ve mikroservis iç iletişimleri

gRPC, Google içindeki servisler arası iletişim ihtiyaçlarını karşılamak üzere geliştirildi. Düşük gecikme ve yüksek throughput gerektiren iç iletişimler için geniş ölçekte kullanılır.

4.2 Netflix, Lyft ve diğer şirket örnekleri

Netflix, gRPC'yi backend‑to‑backend bağlantılarda ve veri akış uygulamalarında denemektedir; Lyft, yüksek performanslı servis ağlarında gRPC ve gRPC streaming kullanır. Ayrıca birçok startup gerçek zamanlı özellikler ve polyglot client desteği nedeniyle gRPC tercih etmektedir.

4.3 Mobil ve IoT senaryoları

gRPC‑Web ve gRPC over HTTP/2 adaptasyonları ile mobil uygulamalar ve edge cihazlar daha verimli ikili protokoller üzerinden sunucularla iletişim kurabilir. Özellikle düşük bant genişliği ve sık bağlantı açma/kapama maliyetinin yüksek olduğu ortamlarda fayda sağlar.

4.4 Streaming örnekleri: telemetry, logging ve real‑time feeds

Telemetry toplama, canlı metrik yayınları, chat/notifications ve video/audio segment dağıtımı gibi uygulamalar gRPC streaming ile performanslı biçimde hayata geçirilir. Server streaming ile örneğin bir sorgunun sonuçları parça parça iletilirken, bidirectional streaming ile gerçek zamanlı iki yönlü iletişim sağlanır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Binary Protobuf serileştirmesi sayesinde düşük bant kullanımı ve hızlı parsing.
• HTTP/2 multiplexing, header compression ve flow control ile yüksek performans.
• Tip güvenli IDL (.proto) ve otomatik code generation ile hata riski azalır.
• Yerleşik streaming modeller ile gerçek zamanlı uygulamalar kolayca inşa edilebilir.

Sınırlamalar

• Tarayıcılar için native destek sınırlıdır — gRPC‑Web veya gateway çözümleri gereklidir.
• Binary format insan tarafından okunabilir değildir; debugging için ek araçlar gerekir.
• HTTP cache gibi CDN tabanlı optimizasyonlar REST/HTTP+JSON kadar doğal değildir.
• Şema yönetimi ve backward compatibility kurallarına dikkat edilmezse sürüm yönetimi karmaşıklaşabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• İç‑servis iletişiminde gRPC tercih edin; client‑facing API'lerde ise REST/GraphQL ile gateway kullanın.
• .proto dosyalarını merkezi bir repo veya schema registry ile yönetin; semver veya deprecation stratejileri belirleyin.
• Deadlines/Timeout ve cancellation token'ları zorunlu kılın; uzun çağrılar için uygun fallback ve retry stratejileri tasarlayın.

Performans optimizasyonu

• Dataloader ve batching kullanarak N+1 sorunlarını azaltın (özellikle resolver mantığı gerektiren durumlarda).
• Message boyutunu küçültmek için Protobuf field tipi seçimine dikkat edin ve gereksiz alanları çıkarın.
• Connection reuse ve keep‑alive parametrelerini doğru konfigüre edin; HTTP/2 connection pooling ile overhead azaltın.

Güvenlik

• mTLS ile servisler arası kimlik doğrulama sağlayın; ayrıca JWT/OAuth token validation ile authorization uygulayın.
• Rate limiting, authentication, authorization ve audit log'larını mutlaka uygulayın; streaming bağlantılarında abuse detection düşünün.

Observability

• OpenTelemetry ile tracing, metrik ve logging toplayın; span'lar içerisinde RPC metadata'yı koruyun.
• Stream length, message size, per‑method latency ve error rate metrikleri toplayın; alert'leri SLA'lara göre yapılandırın.

8. SIK YAPILAN HATALAR

• Tarayıcı gereksinimlerini göz ardı ederek doğrudan gRPC expose etmek — gRPC‑Web veya gateway düşünülmeli.
• .proto sürüm yönetimini ihmal etmek — breaking changes production'da problemlere yol açar.
• Streaming verilerini kontrolsüz kabul etmek — backpressure ve flow control mekanizmalarını uygulamamak kaynak tükenmesine neden olur.
• Binary payload izleme ve debugging için uygun araçları kurmamak — observability zorluğu ortaya çıkar.

9. GELECEK TRENDLER

1. gRPC ve HTTP/3: QUIC üzerinde çalışan gRPC adaptasyonları ile daha düşük bağlantı kurulum maliyeti ve daha iyi mobil performans bekleniyor.
2. Edge‑native gRPC: CDN/edge compute ile kombinlenen gRPC çözümleri, real‑time data processing ve düşük latency uygulamalarını güçlendirecek.
3. AI‑assisted schema evolution: Telemetry'ye dayalı olarak şema optimizasyonları ve otomatik migration önerileri ortaya çıkacak.
4. Federation ve schema registry: Mikroservis bazlı .proto yönetimi için merkezi registry ve federated schema yaklaşımları olgunlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. gRPC her zaman REST'ten daha mı hızlı?

   Genelde Protobuf + HTTP/2 kombinasyonu JSON over HTTP'e göre daha hızlıdır, ancak gerçek hız uygulamaya, mesaj boyutlarına ve network koşullarına bağlıdır. Doğru benchmark ve yük testi yapmak gerekir.

2. 2. Tarayıcılar gRPC'yi nasıl kullanır?

   Tarayıcılar için gRPC‑Web veya HTTP/JSON gateway kullanılmalıdır. gRPC‑Web, browser kompatibilitesi için tasarlanmış bir katman sağlar.

3. 3. gRPC ile caching mümkün mü?

   gRPC için native HTTP caching doğal değildir; ancak response caching, client side cache ve edge cache stratejileri ile getirilebilir. Persisted responses ve key‑based caching kullanılabilir.

4. 4. Protobuf yerine başka IDL kullanabilir miyim?

   Evet; gRPC protokolü esasen Protobuf ile sıkı çalışmak üzere popülerdir fakat farklı serileştirme formatları ve pluggable marshallers ile çalışmak mümkündür. Ancak Protobuf topluluk ve araç desteği açısından öne çıkar.

5. 5. Streaming performansını nasıl ölçerim?

   Message throughput, latency per message, stream duration ve resource usage (CPU/memory) metriklerini toplayın; ayrıca backpressure etkisini izleyin.

6. 6. gRPC ile authentication nasıl sağlanır?

   mTLS servis‑to‑servis kimlik doğrulama için en güçlü yaklaşımdır; üstüne JWT/OAuth token validation eklenebilir. Policy enforcement için API gateway veya service mesh kullanılabilir.

7. 7. gRPC kullanırken hangi metrikleri izlemeliyim?

   RPC count, error count, latency p50/p95/p99, stream open/close, message sizes, connection counts ve per‑method metrics izlenmelidir.

8. 8. gRPC'yi monorepo dışında nasıl yönetmeliyim?

   .proto dosyalarını merkezi schema repo veya artifact registry'de tutun; versioning ve CI pipeline ile otomatik code generation, compatibility checks ve contract tests uygulayın.

Anahtar Kavramlar

Protobuf

Binary serileştirme ve IDL formatı; .proto dosyaları API sözleşmesini tanımlar.

Unary / Streaming

gRPC çağrı tipleri: tek‑tek veya sürekli veri akışı modelleri.

HTTP/2

gRPC'nin taşıyıcı protokolü; multiplexing, flow control ve header compression sağlar.

mTLS

Servis‑to‑servis mutual TLS kimlik doğrulaması.

Backpressure

Stream tüketim hızının üretim hızını kontrol etme mekanizması.

Öğrenme Yol Haritası

1. 0–1 ay: HTTP/2, Protobuf ve temel gRPC konseptlerini öğrenin; basit unary servis implementasyonu yapın.
2. 1–3 ay: Streaming (server/client/bidi) senaryolarını, deadlines/cancellation, ve error handling pratiğini uygulayın.
3. 3–6 ay: gRPC in production: load testing, observability (OpenTelemetry), mTLS, service mesh entegrasyonu ve schema yönetimi üzerinde çalışın.
4. 6–12 ay: Edge gRPC, QUIC/HTTP3 adaptasyonları, federated proto registries ve otomatik schema evolution ile olgunlaşın.