gRPC vs REST vs GraphQL 2026: Performans, Sözleşme ve Üretim Senaryoları Karşılaştırması

2026 itibarıyla modern bir SaaS platformu ortalama 20-80 farklı API endpoint sunar; servisler arası iletişim için 3 ana protokol baskın: REST (yaygın, herkesin bildiği), GraphQL (esnek, frontend dostu) ve gRPC (hızlı, tip-güvenli). API teknolojisi yanlış seçildiğinde proje p99 latency 3-5x artabilir, frontend ekibi her sayfa için 8-15 ek istek atmak zorunda kalabilir, mobil veri tüketimi 2-3x artabilir. Tersine doğru seçimle aynı maliyetle %67 daha hızlı kullanıcı deneyimi sağlanabilir. Türkiye’de gözlemlediğim ekiplerin %64’ü tek protokole sıkışmış (genelde REST) ve mobil + microservice ihtiyaçları arttıkça refactor ağrısı yaşıyor.

Bu rehberde üç protokolün üretim senaryolarındaki performansını, geliştirme deneyimini ve hangi durumda hangisini seçmeniz gerektiğini somut sayılarla aktaracağız. Ayrıca Türkiye’de tipik SaaS mimari kararlarına dair gözlemler ve modern hibrit yaklaşım örnekleri sunacağız.

Üç Protokol Kısa Özet

• REST: HTTP üzerinde resource-based, JSON ile veri taşıma. 25+ yıllık, herkesin bildiği.
• GraphQL: Tek endpoint, query language ile istemcinin ne istediğini söylediği API katmanı (2015, Facebook).
• gRPC: HTTP/2 üzerinde Protocol Buffers (binary), düşük latency, streaming. Google, 2016.

Üç protokol birbirinin alternatifi değil — birbirini tamamlayan araçlar. Doğru mimari kararı, “hangi senaryoda hangisi” sorusunu doğru cevaplamaktan geçer. RESTful tasarım derinleri için REST API tasarım best practice rehberimize, tip-güvenli alternatifler için ise tRPC vs gRPC vs GraphQL içeriğimize göz atabilirsiniz.

Performans Karşılaştırması

Aynı endpoint’in 1.000 paralel istemci ile yapılmış benchmark sonuçları (kontrollü ortam, 10 KB payload):

Metrik	REST (JSON)	GraphQL	gRPC (Protobuf)
p50 latency	22 ms	28 ms	7 ms
p99 latency	78 ms	112 ms	24 ms
Throughput (RPS)	14.000	10.500	42.000
Payload boyutu	10 KB	4-10 KB (sorgu bazlı)	3,2 KB
CPU/req (server)	0,8 ms	1,4 ms	0,3 ms
Geliştirme hızı	Hızlı	Orta	Yavaş başlangıç

Sonuç: gRPC en hızlı, en verimli; ancak browser/native istemci eko sistemi karmaşık. REST en yaygın, en kolay. GraphQL frontend için en esnek ama backend için karmaşık. Tek bir rakam mutlak doğru değildir — yükün karakteristiği (read-heavy vs write-heavy, payload boyutu, ilişki derinliği) sonucu değiştirir.

REST: Ne Zaman Kullanılır?

Avantajları

• Herkes biliyor — onboarding hızlı.
• Browser, mobil, hatta IoT ile uyumlu.
• HTTP cache (CDN) doğal çalışır.
• Postman, curl, Swagger ile test kolay.
• OpenAPI/Swagger ile otomatik dokümantasyon ve kod üretimi.
• Public API olarak sunulması alışkanlık haline gelmiş — partner entegrasyonları için ideal.

Dezavantajları

• Mobil için over-fetching (gereksiz veri taşıma).
• Çoklu ilişki için N+1 istek problemi.
• Tip güvenliği yok (TypeScript ile aşılabilir).
• Streaming sınırlı (SSE veya WebSocket gerek).
• Versiyonlama yönetimi disiplinli olmalı; aksi halde “v17” sorunu çıkar.

İdeal Senaryolar

• Public API (3. parti geliştiriciler için).
• Webhook senaryoları.
• Düşük frekanslı admin paneli API’ları.
• Pure CRUD operasyonlar.
• OpenAPI ile dokümante edilmiş partner entegrasyonları.

API versiyonlama disiplini REST için kritik. API versioning stratejileri rehberimizde URI vs header vs content negotiation karşılaştırması ayrıntılı.

GraphQL: Ne Zaman Kullanılır?

Avantajları

• İstemci sadece ihtiyacı olanı çeker — payload %40-70 azalır mobile.
• Tek endpoint — versiyonlama derdi yok (alan deprecation ile).
• Tip sistemi (schema) — IDE auto-complete, validation.
• Çoklu kaynak federation (Apollo Federation, Hot Chocolate).
• Subscription ile real-time (WebSocket üzerinden).
• Frontend ekibi backend bekleme olmadan UI iterasyonu yapabilir.

Dezavantajları

• HTTP cache çalışmaz (POST kullanır, query body değişir).
• N+1 problemi — DataLoader pattern şart.
• Query complexity attack (kötü niyetli sorgular) — depth/cost limit gerek.
• Sunucu tarafı resolver yazımı daha karmaşık.
• Public API için fazla esnek (rate limiting zor).
• Persisted queries olmadan production’a açmak güvenlik riski.

İdeal Senaryolar

• Mobil + web app aynı backend’i kullanıyor, farklı veri ihtiyaçları var.
• Çoklu microservice’in tek API’da birleştirilmesi gerekiyor (BFF / Federation).
• UI sıkça değişiyor, backend her sayfayı destekleyemiyor.
• Veri grafı karmaşık (ilişki yoğun).
• İç developer portal’ları, design system entegrasyonu.

gRPC: Ne Zaman Kullanılır?

Avantajları

• Çok düşük latency (5-10x daha hızlı REST’e göre).
• HTTP/2 multiplexing — tek bağlantıda paralel çağrı.
• Bi-directional streaming (gerçek zamanlı senaryolar).
• Protocol Buffers ile güçlü tip güvenliği + backward compatibility.
• Otomatik kod üretimi (protoc ile 11+ dil).
• Service mesh (Istio, Linkerd) ile mTLS ve trafik kontrolü doğal.

Dezavantajları

• Browser’da native desteklenmiyor — gRPC-Web gateway gerek.
• Debug zor (binary, curl ile bakılmaz; grpcurl gerek).
• Cache stratejisi karmaşık.
• Public API olarak sunulması alışılmadık.
• Load balancer L7 dengeleyici gerektirir (HTTP/2).
• Proto dosya yönetimi disiplin ister (monorepo veya schema registry).

İdeal Senaryolar

• Microservice’ler arası iç iletişim.
• Düşük latency kritik servisler (ödeme, real-time bidding, oyun).
• Streaming gerekli (video, telemetri).
• Polyglot ekip — birçok dilde aynı API.
• Sidecar service mesh (Linkerd/Istio) ile mTLS + retries.

gRPC ile mikroservis derin dalış için gRPC + Protobuf üretim rehberini okumanızı öneririm; mesh tarafında ise eBPF + Cilium içeriğimiz sidecar’sız mesh deneyimini anlatıyor.

Hibrit Yaklaşım: 2026 Standart

2026’da modern bir SaaS şirketi tek protokol değil, üçünün karması ile çalışır:

• gRPC: Microservice → microservice (iç iletişim).
• GraphQL: Mobil/web frontend → backend (BFF katmanı).
• REST: Public API, webhook, 3. parti entegrasyon.

Bu yaklaşım her protokolün güçlü yönünü kullanır. Tipik mimari:

• Frontend → GraphQL gateway (Apollo/Hot Chocolate).
• GraphQL gateway → microservice’ler (gRPC).
• Public API → REST endpoints (OpenAPI dokümantasyon).
• Webhook → REST POST.
• Real-time → GraphQL subscription veya gRPC streaming.

Türkiye Özelinde Pratik Notlar

• Banka entegrasyonları: BKM/Iyzico/Param hâlâ REST+JSON ya da SOAP. Public API katmanı REST kalmalı; iç iletişim gRPC’ye dönüşebilir.
• Mobil veri maliyeti: 4G/5G kapsama dışında gRPC veya GraphQL ile payload düşürmek conversion’ı korur.
• Senior backend kıtlığı: gRPC + proto dosya yönetimi disiplini gerektirir; junior-ağırlıklı ekiplerde GraphQL daha yumuşak iniş.
• Public API + partner: Türkiye’de partner ekosistemi henüz GraphQL’e alışkın değil — REST + OpenAPI standart.
• Yapay zekâ entegrasyonları: LLM provider’lar (OpenAI/Anthropic) REST streaming kullanıyor; gateway’iniz SSE/streaming desteklemeli.

Versiyonlama Stratejisi

• REST: URL path versiyonlama (/v1/, /v2/) veya header.
• GraphQL: Alan deprecation, versiyonlama yok (“schema evolution”).
• gRPC: Protobuf paket versiyonlama (v1, v2 paket isimleri), backward compatibility.

Güvenlik

• Authentication: Hepsi için OAuth 2.1 / OIDC standart.
• Authorization: Resource-level (REST), field-level (GraphQL), method-level (gRPC).
• Rate limiting: REST kolay (endpoint başına), GraphQL zor (query complexity), gRPC orta.
• TLS: Hepsi için zorunlu (HTTP/2 + TLS 1.3).
• Schema sızıntısı: GraphQL introspection production’da kapalı veya auth-gated.

Anti-Pattern ve Yaygın Hatalar

• “GraphQL her şeye çözüm”: Public API’yi GraphQL ile açmak rate limit ve cache’i mahveder.
• gRPC’yi mobil’e doğrudan: mTLS sertifikası, HTTP/2 LB, gRPC-Web gateway karmaşıklığı atlanır.
• REST’i microservice arası: Sync REST chain’leri p99’u kümülatif artırır; gRPC veya event-driven daha sağlıklı.
• Persisted query yok: GraphQL endpoint’i abuse edilebilir; persisted queries + APQ şart.
• OpenAPI yok: REST + spec yok → consumer’lar dokümantasyon eksikliğinden mahvolur.

Sık Sorulan Sorular

Ömer Önal’dan pratik not: Türkiye’de API teknoloji kararı verirken ekiplerin yaptığı en yaygın hata, “bu yıl popüler olan ne ise onu seçmek”. 2018’de “her şey GraphQL’e” akımı, 2022’de “her şey gRPC’ye”, 2024’te “tRPC kazandı” — her dönemde aşırı pendulum salınımı oldu. Doğru karar şu sırayla verilmeli: kim consumer (public/partner/iç frontend/iç microservice), trafik karakteri (read/write/stream), ekip yetkinliği, mevcut altyapı. Bu 4 boyutta cevap çıktıktan sonra protokol kendiliğinden seçilir. Genelde 50 kişiyi geçen şirketlerde 2 protokol birden yaşar (REST public + gRPC iç) ve bu sağlıklıdır. Sizin sisteminizde şu an hangi protokol baskın — REST monolit mi, microservice gRPC mi, yoksa GraphQL gateway ile hibrit mi?

Sonuç

API teknolojisi seçimi mimari karar olmadan, performans, ekip yetkinliği ve istemci profili birlikte değerlendirilerek yapılmalı. 2026 standardı REST + GraphQL + gRPC hibrit mimari; her birinin güçlü yönü kullanılıyor. Doğru seçim p99 latency’i %50-70 düşürür, mobil veri tüketimini %40 azaltır ve geliştirme sürelerini %25 hızlandırır. API stratejisini tamamlayan içeriklerimiz: event-driven architecture rehberi, eBPF + Cilium ile Kubernetes ağı, webhook mimarisi ve API gateway karşılaştırması. İletişim formundan projeniz için mimari değerlendirme talep edebilirsiniz.

Dış otorite kaynaklar: gRPC · GraphQL · Connect-RPC · OpenAPI Initiative