gRPC ve Modern API Protokolleri Rehberi [2026]

Giris: REST Otesinde API Protokolleri

Modern yazilim mimarileri, mikroservislerin birbirleriyle hizli ve guvenilir sekilde iletisim kurmasini gerektirir. REST ve GraphQL uzun yillar boyunca API gelistirmenin temel taslarini olustursa da, yuksek performans ve tip guvenligi gerektiren senaryolarda bu protokoller yetersiz kalabilir. Ozellikle servisler arasi iletisimde dusuk gecikme suresi, verimli veri serializasyonu ve cift yonlu streaming gibi ihtiyaclar, gRPC gibi modern protokollerin on plana cikmasina neden olmustur.

2026 itibariyla mikroservis mimarileri yayginlastikca, servisler arasi iletisim protokolu secimi stratejik bir karar haline gelmistir. Yanlis protokol secimi, sistemin genel performansini olumsuz etkileyebilir, gelistirme surelerini uzatabilir ve operasyonel karmasikligi artirabilir.

Bu rehberde gRPC'yi derinlemesine inceleyecek, Protocol Buffers yapisini anlayacak, farkli cagri turlerini karsilastiracak ve tRPC gibi alternatif yaklasimlarla birlikte modern API protokollerinin tum boyutlarini ele alacagiz.

gRPC Nedir ve Nasil Calisir?

gRPC, Google tarafindan gelistirilen acik kaynakli bir Remote Procedure Call (RPC) framework'udur. HTTP/2 uzerinde calisan gRPC, Protocol Buffers (protobuf) kullanarak veri serializasyonu yapar. Bu yaklasim, JSON tabanli REST API'lere kiyasla onemli olcude daha kucuk mesaj boyutlari ve daha hizli islem sureleri saglar. Google, Netflix, Square ve Cisco gibi buyuk teknoloji sirketleri, dahili servis iletisimlerinde gRPC'yi yaygin olarak kullanmaktadir.

Protocol Buffers ve Servis Tanimlama

gRPC'nin temelinde Protocol Buffers yer alir. Protobuf, dile bagimsiz bir arayuz tanimlama dili (IDL) sunar. Bir .proto dosyasinda servis tanimlarinizi ve mesaj yapilarinizi bildirirsiniz:

syntax = "proto3";

service OrderService {
  rpc CreateOrder (CreateOrderRequest) returns (OrderResponse);
  rpc GetOrderStream (OrderFilter) returns (stream OrderResponse);
  rpc SendOrderUpdates (stream OrderUpdate) returns (BatchResponse);
  rpc OrderChat (stream OrderMessage) returns (stream OrderMessage);
}

message CreateOrderRequest {
  string customer_id = 1;
  repeated OrderItem items = 2;
  string shipping_address = 3;
}

message OrderResponse {
  string order_id = 1;
  string status = 2;
  double total_amount = 3;
}

Bu tanimdan protoc derleyicisi ile Go, Java, Python, C#, TypeScript gibi dillerde otomatik olarak istemci ve sunucu kodlari uretilir. Kod uretimi, tip guvenligini garanti altina alir ve el ile yazilan serializasyon kodunun hata riskini ortadan kaldirir. Protobuf'un alan numaralama sistemi, geriye donuk uyumlulugu saglar; mevcut alanlarin numaralari degistirilmedigi surece yeni alanlar eklenebilir.

Kod Uretimi ve Gelistirme Akisi

Tipik bir gRPC gelistirme akisi su adimlari icerir: Oncelikle .proto dosyalarinda servis kontrati tanimlanir. Ardindan protoc veya buf gibi araclarla hedef dilde stub kodlari uretilir. Sunucu tarafinda uretilen arayuzler implement edilir, istemci tarafinda ise uretilen stub'lar dogrudan kullanilir.

buf araci, proto dosyalarinin yonetimini modernize eder. Lint kurallari ile proto dosyalarinin tutarliligini saglar, breaking change tespiti yapar ve kod uretimini yapilandirmali hale getirir. Buyuk ekiplerde proto dosyalarinin merkezi bir depoda yonetilmesi ve CI/CD pipeline'inda otomatik kod uretimi yapilmasi, servis kontratlarinin tutarliligini garanti eder.

gRPC Cagri Turleri

gRPC dort farkli iletisim modeli destekler ve her biri farkli kullanim senaryolarina yoneliktir. Bu esneklik, gRPC'yi farkli iletisim ihtiyaclarini tek bir framework icinde karsilayabilen guclu bir arac haline getirir.

Unary (Tekil) Cagrilar

En basit gRPC cagri turudur. Istemci tek bir istek gonderir, sunucu tek bir yanit dondurur. REST API'deki tipik istek-yanit dongusuyle benzerlik tasir. Kullanici olusturma, siparis sorgulama, kimlik dogrulama gibi standart CRUD operasyonlari icin idealdir. Cogu gRPC uygulamasinda cagrilarin buyuk cogunlugu unary tipindedir.

Server Streaming

Istemci tek bir istek gonderir, sunucu bir dizi yanit akisi dondurur. Ornegin bir raporlama servisinde buyuk veri kumesinin parcalar halinde iletilmesi veya canli fiyat guncellemelerinin istemciye aktarilmasi icin kullanilir. Sunucu, veri hazir oldukca istemciye gonderir ve istemci bu veriyi siralama garantisiyle alir. Finansal veri terminalleri, haber akislari ve log izleme sistemleri, server streaming'in tipik kullanim alanlarindandir.

Client Streaming

Istemci bir dizi mesaj gonderir, sunucu tum mesajlari aldiktan sonra tek bir yanit dondurur. Dosya yukleme, toplu veri aktarimi veya sensor verilerinin toplanmasi gibi senaryolarda tercih edilir. Istemci tum verileri gonderdikten sonra sunucu islemi tamamlar ve sonucu dondurur. Bu model, buyuk veri kumelerinin parcalar halinde gonderilmesini gerektiren durumlarda bellek kullanimini optimize eder.

Bidirectional Streaming

Her iki taraf da es zamanli olarak mesaj akisi gonderip alabilir. Sohbet uygulamalari, gercek zamanli isbirlikci duzenleme veya multiplayer oyun sunuculari gibi karmasik gercek zamanli iletisim senaryolari icin kullanilir. Her iki taraf bagimsiz olarak okuma ve yazma yapabilir, bu da yuksek esneklik saglar. Mesaj sirasi her yonde bagimsiz olarak korunur ancak iki yon arasinda siralama garantisi yoktur.

gRPC vs REST vs GraphQL Karsilastirmasi

Performans ve Verimlilik

gRPC, ikili (binary) serializasyon sayesinde REST'in JSON formatina kiyasla ortalama yuzde 30-50 daha kucuk mesaj boyutlari uretir. HTTP/2 multiplexing ozelligi sayesinde tek bir TCP baglantisi uzerinden birden fazla istek es zamanli islenebilir. Header compression (HPACK) ise tekrarlayan header bilgilerinin bant genisligi tuketimini azaltir. Benchmark testlerinde gRPC, ozellikle yuksek hacimli mikroservis iletisiminde REST'e kiyasla 5-10 kat daha dusuk gecikme suresi gosterebilir.

GraphQL ise istemci tarafinda veri ihtiyacini optimize etmede gucludur ancak sunucu tarafinda sorgu analizi ve cozumleme maliyeti tasir. REST, basitligi ve genis ekosistemi ile hala bircok senaryo icin yeterlidir. Her protokolun guclü oldugu alan farklidir ve dogru secim kullanim senaryosuna baglidir.

Gelistirici Deneyimi

REST, en genis tooling destegine ve ogrenim kaynaklarina sahiptir. Postman, Swagger, curl gibi araclarla kolayca test edilebilir. GraphQL, esnek sorgu yapisi ile frontend gelistiricilere buyuk kolaylik saglar ve GraphiQL gibi araclarla kesif odakli gelistirme sunar. gRPC ise tip guvenligi ve otomatik kod uretimi ile ozellikle backend servisler arasi iletisimde ustun bir gelistirici deneyimi sunar. Ancak tarayici desteginin sinirli olmasi ve ikili protokolun insan tarafindan okunamamasi, gRPC'nin dogrudan frontend'de kullanimini ve hata ayiklamasini zorlastirir.

Kullanim Alanlari

REST, genel amacli web API'leri ve ucuncu taraf entegrasyonlari icin idealdir. GraphQL, karmasik veri iliskileri olan ve farkli istemci ihtiyaclari bulunan uygulamalar icin uygundur. gRPC ise mikroservisler arasi yuksek performansli iletisim, gercek zamanli veri akisi ve mobil backend'ler icin en iyi secenektir.

tRPC: TypeScript Tabanli Full-Stack RPC

tRPC, TypeScript ekosisteminde giderek daha fazla benimsenen bir RPC framework'udur. Proto dosyalari veya kod uretimi gerektirmeden, TypeScript'in tip sistemini kullanarak sunucu ve istemci arasinda tam tip guvenligi saglar.

tRPC'nin Avantajlari ve Sinirlamalari

tRPC'de sunucuda tanimlanan bir endpoint'in tip bilgisi, herhangi bir kod uretimi olmadan dogrudan istemcide kullanilabilir. Sunucuda bir router tanimladiginizda, istemci tarafinda bu router'in tum endpoint'lerini otomatik tamamlama ile gorebilir ve tip hatalarini derleme zamaninda yakalayabilirsiniz. Bu, TypeScript monorepo yapilarinda son derece verimli bir gelistirme deneyimi sunar. Next.js, Nuxt ve SvelteKit gibi framework'lerle sorunsuz entegrasyon saglar.

Ancak tRPC yalnizca TypeScript projeleri icin uygundur. Farkli dillerde yazilmis servislerin iletisiminde gRPC, dile bagimsiz yapisi ile avantajlidir. Ayrica tRPC, servisler arasi iletisimden ziyade frontend-backend iletisimi icin optimize edilmistir. Smart Maple olarak projelerimizde ihtiyaca gore her iki teknolojiyi de degerlendirerek en uygun cozumu belirliyoruz.

gRPC-Web: Tarayici Istemcileri

gRPC'nin en onemli sinirliklarindan biri, tarayicilarin HTTP/2 trailer'larini ve ikili frame'leri dogrudan desteklememesidir. gRPC-Web bu sorunu cozmek icin gelistirilmistir. Bir proxy katmani (genellikle Envoy) uzerinden tarayici istemcilerinin gRPC servislerine erisimini saglar.

gRPC-Web, unary ve server streaming cagrilarini destekler. Client streaming ve bidirectional streaming icin ise WebSocket tabanli cozumler veya alternatif yaklasimlar gerekir. Uretim ortaminda gRPC-Web kullanirken Envoy proxy yapilandirmasinin dogru yapilmasi ve CORS ayarlarinin dikkatlice duzenlenmesi kritik oneme sahiptir. Connect protokolu, gRPC-Web'e modern bir alternatif olarak ortaya cikmis olup hem gRPC hem de HTTP/JSON uyumlu calisabilme esnekligi sunar.

gRPC'de Yuk Dengeleme

HTTP/2 uzerinde calisan gRPC, geleneksel Layer 4 (TCP) yuk dengeleyicilerle uyumsuzluk yasayabilir. Cunku HTTP/2, tek bir uzun omurlu baglanti uzerinden tum istekleri coklar (multiplexing). Bu durumda Layer 4 yuk dengeleyici, tum istekleri ayni backend sunucusuna yonlendirir ve dagitim dengesizligi olusur. Bu nedenle gRPC icin Layer 7 (uygulama katmani) yuk dengeleme tercih edilmelidir.

Kubernetes ortaminda headless service ile istemci tarafli yuk dengeleme veya Envoy, Linkerd gibi service mesh cozumleri kullanilabilir. Istemci tarafli yuk dengelemede gRPC'nin yerlesik name resolver ve load balancer API'leri, round-robin veya weighted round-robin stratejileri ile dengeli dagitim saglar. Bulut ortamlarinda AWS ALB, Google Cloud Load Balancer gibi gRPC destekli yuk dengeleyiciler tercih edilmelidir.

Kimlik Dogrulama ve Interceptor'lar

gRPC, interceptor mekanizmasi ile isteklerin islenme surecine mudahale etmeyi mumkun kilar. Bu mekanizma, kimlik dogrulama, yetkilendirme, loglama, metrik toplama ve hiz sinirlandirma gibi cross-cutting concern'leri yonetmek icin kullanilir.

Kimlik Dogrulama Yontemleri

gRPC, TLS ile kanal duzeyi guvenlik saglar. Karsilikli TLS (mTLS) ile hem sunucu hem de istemci kimlik dogrulamasi yapilabilir; bu ozellikle servisler arasi iletisimde zero-trust guvenlik modeli icin onemlidir. Metadata uzerinden JWT token veya API key iletimi ile cagri duzeyi kimlik dogrulama yapilabilir.

Interceptor'lar hem unary hem de streaming cagrilar icin tanimlanabilir. Sunucu tarafinda bir interceptor zinciri olusturarak kimlik dogrulama, yetkilendirme, istek loglama ve metrik toplama islemlerini sirali olarak calistirmak mumkundur. Istemci tarafinda ise interceptor'lar, her istege otomatik olarak token eklemek veya yeniden deneme mantigi uygulamak icin kullanilir.

Hata Yonetimi

gRPC, standart hata kodlari tanimi sunar. OK, NOT_FOUND, PERMISSION_DENIED, INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED gibi on tanimli kodlar, REST'in HTTP durum kodlarina benzer sekilde calismakla birlikte daha spesifik anlam tasir. Ornegin UNAVAILABLE gecici bir hataya isaret ederken INTERNAL kalici bir sunucu hatasini belirtir; bu ayrima REST'in genel 500 durum kodunda ulasmak zordur.

Zengin hata detaylari icin google.rpc.Status mesaji kullanilabilir. Bu yaklasim, hata mesajina ek olarak yapilandirilmis hata bilgisi eklemeye imkan tanir. Ornegin bir dogrulama hatasinda hangi alanlarin gecersiz oldugu ve her alan icin hata aciklamasi ayrintili olarak iletilebilir. Bu zengin hata modeli, istemci tarafinda hatalarin programatik olarak islenmesini kolaylastirir.

Retry politikalari da gRPC yapilandirmasinin onemli bir parcasidir. Idempotent cagrilar icin otomatik yeniden deneme, ustel geri cekilme (exponential backoff) ve deadline propagation gibi stratejiler uygulanarak hata dayanikliligi arttirilir. Deadline mekanizmasi, bir istege maksimum bekleme suresi tanimlayarak kaynak israfini onler ve zincir halindeki servis cagrilarinda deadline'in otomatik olarak yayilmasini saglar.

Performans Olcumleri ve Karsilastirma

Gercek dunya testlerinde gRPC'nin performans avantajlari belirgin sekilde ortaya cikar. Tipik bir mikroservis iletisiminde gRPC, REST'e kiyasla ortalama 2-3 kat daha dusuk gecikme suresi gosterir. Yuksek hacimli senaryolarda bu fark 5-10 kata kadar cikabilir.

Mesaj boyutu acisindan protobuf, JSON'a kiyasla ortalama yuzde 40-60 daha kucuk veri uretir. Bu, ozellikle mobil aglar ve bant genisligi kisitli ortamlarda buyuk avantaj saglar. CPU kullanimi acisindan ise protobuf serializasyonu JSON parse etme islemine kiyasla onemli olcude daha verimlidir. Buyuk veri yapilari icin bu fark daha da belirgin hale gelir.

Ancak performans degerlendirmesinde yalnizca ham hiz olcumlerine bakmak yeterli degildir. Gelistirme suresi, hata ayiklama kolayligi, ekosistem uyumlulugu ve operasyonel karmasiklik da toplam maliyet hesabina dahil edilmelidir.

Kullanim Senaryolari

Mikroservis Iletisimi

gRPC'nin en yaygin kullanim alani, mikroservisler arasindaki dahili iletisimdir. Tip guvenligi, yuksek performans ve coklu dil destegi, buyuk olcekli dagitik sistemlerde gRPC'yi ideal kilar. Servis kontrati proto dosyasinda merkezi olarak yonetildigi icin ekipler arasi uyum kolayca saglanir. Farkli dillerde yazilmis servislerin sorunsuz iletisim kurmasi, polyglot mimarilerde buyuk avantaj saglar.

Gercek Zamanli Streaming

Finansal veri akislari, IoT sensor verileri, canli konum takibi gibi gercek zamanli veri iletimi gerektiren senaryolarda gRPC streaming cagrilari, WebSocket'lere alternatif olarak guclu bir cozum sunar. Otomatik akis kontrolu ve geri basinca (backpressure) yonetimi, streaming senaryolarinda guvenilirlik saglar. WebSocket'lerin aksine gRPC streaming, tip guvenli mesajlar ve yerlesik hata yonetimi sunar.

Mobil Backend'ler

Mobil uygulamalar icin gRPC, kucuk mesaj boyutlari sayesinde veri tuketimini azaltir. Protobuf'un ikili formati, hem bant genisligi hem de pil tuketimi acisindan avantaj saglar. gRPC'nin deadline ve iptal mekanizmalari, mobil aglardaki degisken baglanti kosullarina uyum saglar. Kullanici bir ekrani terk ettiginde devam eden gRPC cagrilari iptal edilerek gereksiz kaynak kullanimi onlenir.

IoT ve Edge Computing

IoT cihazlari genellikle sinirli kaynaklara sahiptir. gRPC'nin verimli serializasyonu ve kucuk mesaj boyutlari, bu ortamlarda ideal iletisim cozumu sunar. Cift yonlu streaming sayesinde cihazlardan gelen sensor verileri surekli olarak islenir ve cihazlara komutlar gercek zamanli olarak iletilir. gRPC-lite gibi hafif implementasyonlar, kaynak kisitli cihazlarda bile gRPC kullanimini mumkun kilar.

Dogru Protokolu Secmek

Protokol secimi, projenin gereksinimlerine bagli olarak degisir. Genel amacli web API'leri ve genis ekosistem ihtiyaci icin REST ilk tercihtir. Karmasik veri iliskileri ve esnek sorgulama icin GraphQL degerlendirilmelidir. Mikroservisler arasi yuksek performansli iletisim ve streaming icin gRPC en uygun secenektir. TypeScript monorepo yapilarinda ise tRPC sadelik ve verimlilik saglar.

Cogu buyuk olcekli sistemde bu protokoller birlikte kullanilir. Dis dunyaya REST veya GraphQL ile acilan bir API Gateway'in arkasinda, dahili servisler gRPC ile iletisim kurabilir. Bu hibrit yaklasim, her protokolun guclü yonlerinden faydalanirken zayif yonlerini telafi eder. Smart Maple olarak, her projenin kendine ozgu ihtiyaclarini analiz ederek dogru protokol kombinasyonunu belirlemeyi oneririz.

Sonuc

gRPC ve modern API protokolleri, yazilim mimarilerinin performans ve olceklenebilirlik ihtiyaclarini karsilamada kritik rol oynar. Protocol Buffers ile tip guvenli servis tanimlama, HTTP/2 uzerinde yuksek performansli iletisim ve dort farkli streaming modeli, gRPC'yi mikroservis ekosistemlerinin vazgecilmez bir parcasi haline getirmistir. tRPC gibi yeni nesil araclar ise belirli ekosistemler icinde daha da yuksek gelistirici verimliligi sunmaktadir. Dogru senaryoda dogru protokolu secmek, sistemin genel performansi ve bakimlanabilirligi uzerinde dogrudan etkili olacaktir.