gRPC vs REST: hangi koşulda hangisi mantıklı?

gRPC son 5 yılda microservice ekosisteminin default tercihi oldu. REST ise hala public API’lerin çoğunluğu. Hangi durumda hangisi daha uygun?

Microservice projesinde gRPC, monolith ve public API projesinde REST kullandığım 4 farklı projede çıkardığım ders.

gRPC nedir, REST’ten farkı

REST: HTTP/1.1 veya HTTP/2 üzerinde JSON body, endpoint = URL. Herkesin bildiği.

gRPC: HTTP/2 + Protocol Buffers (protobuf) binary format + RPC-style method call. Google tarafından geliştirildi, CNCF standardı.

Özet farklar:

gRPC’nin güçlü olduğu alanlar

Service-to-service iletişim. İki backend servis arasında iletişimde gRPC açık ara önde. Payload daha küçük, serialization/deserialization 5-10x hızlı, HTTP/2 multiplexing ile connection sayısı azalıyor. Microservice environment’ında bu performans farkı fatura farkına dönüşüyor.

Contract-driven development. .proto dosyası kontrat oluyor. Client ve server kodunu aynı .proto’dan generate ediyorsunuz. Type safety, versioning, breaking change detection yerleşik geliyor. API dokümantasyonu .proto’nun kendisi zaten.

Streaming kullanım durumları. gRPC 4 tür streaming destekliyor:

Unary (normal request/response)
Server streaming (server sürekli gönderiyor)
Client streaming (client sürekli gönderiyor)
Bidirectional streaming

Chat uygulaması, real-time dashboard, telemetri ingestion, machine learning model serving gibi stream-heavy use case’lerde gRPC çok ergonomik.

Polyglot ekip. 5 farklı dilde servis yazıyorsanız (Go, Python, Node, Java, Rust) .proto file protocol buffer compiler’ları ile her dilde aynı client/server üretiliyor. Manual SDK yazma ihtiyacı ortadan kalkıyor.

REST’in güçlü olduğu alanlar

Public API. Dünya REST konuşuyor. SDK’ları REST için var, postman’de REST’i kolay test ediyorsunuz, browser’dan direkt çağırabiliyorsunuz, developer onboarding hızlı.

Browser-native support. Browser gRPC konuşamıyor (HTTP/2 trailer’ı desteklemiyor). gRPC-Web proxy çözümü var ama ek infra katmanı. Basit bir SPA için fetch() ile REST çağırmak zahmetsiz.

Debugging ergonomics. REST request’ini cURL ile test, header’lar insan-okunur, body insan-okunur. gRPC’de binary payload, grpcurl ile test etmeniz, sertifika ve metadata ile uğraşmanız gerek.

CDN ve caching. HTTP caching REST’le doğal, CDN’e koyabilirsiniz, ETag / If-None-Match negotiation yerleşik. gRPC bu infrastructure’ın dışında kalıyor.

Kütüphane ekosistemi. WordPress plugin’i, mobile SDK, 3rd party tool integration, analytics tool REST bekliyor. gRPC’yi dışarı açınca integration partner’larınızdan şikayet gelir.

Karar matrisim

Yeni servis tasarlarken şu soruları soruyorum:

Kim consumer? İç servis mi, mobile app mi, public developer mı?
– İç servis: gRPC favori
– Mobile app: her ikisi de ok, REST daha yaygın
– Public API: REST (gRPC developer friction yaratır)
Performans kritik mi?
– Sub-milisaniye latency gerekli: gRPC
– 50ms latency ok: REST yeter
Streaming ihtiyacı var mı?
– Yes: gRPC baştan düşün
– No: REST ok
Ekip nasıl?
– Polyglot, service-oriented: gRPC
– WordPress / PHP heavy, tek dil: REST
Tooling olgunluğu?
– Kubernetes + service mesh (Istio/Linkerd) var: gRPC mesh ile iyi oturuyor
– Klasik LAMP veya tek-server setup: REST daha basit

Hybrid yaklaşım yaygınlaşıyor

Büyük şirketlerin çoğunda şu pattern oluşuyor:

İç servis-servis: gRPC
Edge (public API, client-facing): REST (ya da GraphQL)
Gateway katmanı iki dünyayı köprüler (gRPC backend → REST edge)

Bu yaklaşım her iki dünyanın güçlü yanını alıyor. gRPC’den performans, REST’ten ekosistem.

gRPC’ye geçişteki sürpriz zorluklar

Bir ekip gRPC’ye geçmek isterse hazırlanması gereken şeyler:

Load balancer. HTTP/1.1 LB’ler gRPC’yi düzgün balance edemiyor (long-lived HTTP/2 connection’lar nedeniyle). Envoy, Linkerd, veya gRPC-aware LB gerekli.

Deadline ve retry semantics. gRPC’de deadline context ile propagate olmalı, retry idempotency-aware olmalı. REST’ten daha dikkatli yapılmalı.

Observability. Request tracing için OpenTelemetry instrumentation, Prometheus metrics (gRPC özel label’lar) setup gerekli. REST’teki HTTP access log refleksi yetmez.

Breaking change avoidance. .proto dosyasında field number’ları asla değiştirmeyin, remove edilen field’ın number’ını asla reserved tutmadan serbest bırakmayın. Yoksa wire format uyumsuzluğu çıkar.

Sonuç

gRPC ve REST ideolojik bir tartışma olmaktan çıktı, use case’e göre seçim. REST’i erken gömenler public API’de yalnızlaşıyor, gRPC’yi asla kullanmayanlar microservice dünyasında performans bırakıyor.

Karar: consumer’ına göre, ekibine göre, ürününün aşamasına göre seçim yap. Ezberle tek taraflı tercih bazen 2 yıl sonra geri dönmen gereken bir karar oluyor.