API Tasarımı & İletişim Protokolleri 45 okunma

REST, GraphQL ve gRPC Karşılaştırması

REST, GraphQL ve gRPC arasındaki temel farklar, performans karşılaştırmaları, kullanım senaryoları ve .NET ekosistemindeki uygulama stratejileri ele alınır. Hangi API teknolojisinin hangi proje için uygun olduğu, hibrit yaklaşımlar ve gelecek trendleri değerlendirilir.

REST, GraphQL ve gRPC Karşılaştırması

REST vs. GraphQL vs. gRPC: Doğru API Teknolojisini Seçme Rehberi

Modern yazılım geliştirmede, uygulamalar arası iletişim için doğru API teknolojisini seçmek, sistemin performansından geliştirici deneyimine kadar birçok faktörü doğrudan etkiler. REST, GraphQL ve gRPC, günümüzde en yaygın kullanılan üç API yaklaşımıdır. Her biri farklı ihtiyaçlar için tasarlanmıştır ve güçlü/yönlü oldukları alanlar vardır. Bu yazıda, bu üç teknolojiyi; veri modelleme, performans, ölçeklenebilirlik, güvenlik ve kullanım senaryoları açısından derinlemesine karşılaştıracak, projeniz için en doğru seçimi yapmanıza yardımcı olacak bir rehber sunacağız.

1. Hızlı Karşılaştırma Tablosu

Kriter REST (HTTP/JSON) GraphQL gRPC
Temel Felsefe Kaynak odaklı (Resource-based) Sorgu odaklı (Query-based) Prosedür odaklı (RPC)
Veri Aktarım Formatı JSON (çoğunlukla) JSON Protobuf (Binary)
Protokol HTTP/1.1, HTTP/2 HTTP/1.1, HTTP/2 HTTP/2, HTTP/3
Sorgulama Esnekliği Düşük (Sabit endpoint'ler) Yüksek (İstemci ihtiyacına göre) Düşük (Sabit metotlar)
Over-fetching / Under-fetching Evet (Çok yaygın) Hayır (Tam kontrol) Hayır (Metot bazlı)
Cache Desteği HTTP Cache (Güçlü) Zor (Normalizasyon gerekir) Zor (HTTP/2 Akışı)
Performans Orta Orta (Sorgu karmaşıklığına bağlı) Çok Yüksek (Binary + HTTP/2)
Tarayıcı Desteği Çok İyi İyi (Apollo Client) Sınırlı (gRPC-Web)
Güçlü Tipli (Type-Safe) Zayıf (OpenAPI ile) Güçlü (GraphQL Schema) Çok Güçlü (Protobuf)
Streaming Kısıtlı (HTTP/2 ile) Kısıtlı Çift Yönlü (Bi-directional)
Öğrenme Eğrisi Düşük Orta-Yüksek Yüksek
.NET Entegrasyonu ASP.NET Core Web API Hot Chocolate, GraphQL.NET gRPC for .NET

2. REST: Olgun, Yaygın ve Güvenilir

REST (Representational State Transfer), Roy Fielding tarafından tanımlanan ve HTTP protokolünün doğal yapısını kullanan bir mimari stildir. Kaynaklar (resources) URI'ler ile tanımlanır ve HTTP metotları (GET, POST, PUT, DELETE) ile yönetilir.

Güçlü Yönleri:

  • Olgunluk ve Yaygınlık: En yaygın API standardıdır. Herkesin bildiği ve anladığı bir yaklaşımdır.

  • HTTP Cache Desteği: HTTP protokolünün cache mekanizmaları (Cache-Control, ETag) doğrudan kullanılabilir.

  • Tarayıcı Desteği: Tüm tarayıcılar REST API'lerini doğrudan tüketebilir (fetch, XMLHttpRequest).

  • Dokümantasyon: Swagger/OpenAPI ile otomatik ve interaktif dokümantasyon oluşturulabilir.

  • Basitlik: Öğrenmesi ve uygulaması en kolay yaklaşımdır.

Zayıf Yönleri:

  • Over-fetching: İhtiyaç duyulandan fazla veri döner. (Örn: /users/123 endpoint'i tüm kullanıcı bilgilerini döner, sadece isim ve e-posta yetebilir).

  • Under-fetching: Yeterli veri gelmez, birden fazla endpoint'e çağrı yapmak gerekir (N+1 problemi).

  • Büyük Payload: JSON metin tabanlı olduğu için binary protokollere göre daha fazla bant genişliği kullanır.

  • Versiyonlama Zorluğu: API değişiklikleri yeni endpoint'ler veya yeni sürümler gerektirir (/v1/users, /v2/users).

3. GraphQL: Esneklik ve İstemci Kontrolü

GraphQL, Facebook tarafından geliştirilen bir sorgu dili ve çalışma zamanıdır. İstemci, ihtiyaç duyduğu verileri tam olarak belirtebilir; sunucu, istenen alanları içeren bir yanıt döner.

Güçlü Yönleri:

  • Over/Under-fetching Yok: İstemci tam olarak ihtiyacı olan veriyi talep eder.

  • Tek Endpoint: Tüm sorgular tek bir endpoint'ten (/graphql) yapılır.

  • Güçlü Tip Sistemi: Schema, tüm veri modellerini ve ilişkileri net bir şekilde tanımlar.

  • İstemci Tarafı Önbellekleme (Apollo Client): Sorgu normalizasyonu ile güçlü önbellekleme sunar.

  • Dökümantasyon: Schema, kendi dokümantasyonunu oluşturur (GraphiQL, Playground).

  • Hızlı Prototipleme: Frontend ekipleri, backend değişikliğine ihtiyaç duymadan yeni veri ihtiyaçlarını karşılayabilir.

Zayıf Yönleri:

  • Karmaşıklık: REST'ten daha karmaşıktır. Öğrenme eğrisi daha diktir.

  • Cache Zorluğu: HTTP cache, GraphQL sorguları için doğrudan çalışmaz (aynı sorgu farklı veriler dönebilir).

  • N+1 Sorgu Problemi: Veritabanı katmanında, ilişkili verileri yüklerken optimize edilmezse performans düşebilir (DataLoader ile çözülür).

  • Büyük Sorgu Maliyeti: İstemci, sunucuyu zorlayan çok büyük ve iç içe sorgular gönderebilir (query depth/ complexity analizi ile korunur).

4. gRPC: Performans ve Düşük Gecikme

gRPC (gRPC Remote Procedure Call), Google tarafından geliştirilen, HTTP/2 üzerinde çalışan, Protobuf (Protocol Buffers) ile binary serileştirme kullanan bir RPC (Remote Procedure Call) framework'üdür.

Güçlü Yönleri:

  • Yüksek Performans: Protobuf binary formatı, JSON'dan çok daha hızlı serileştirir ve daha az bant genişliği kullanır.

  • Düşük Gecikme: HTTP/2'nin multiplexing ve header compression özelliklerinden yararlanır.

  • Güçlü Tipli (Type-Safe): .proto dosyaları ile sözleşme (contract) tanımlanır, otomatik istemci/sunucu kod üretimi yapılır.

  • Çift Yönlü Streaming: Bi-directional streaming ile gerçek zamanlı uygulamalar için idealdir.

  • Çoklu Dil Desteği: .proto dosyalarından C#, Java, Go, Python, C++ gibi birçok dil için kod üretilebilir.

  • gRPC-Web: Tarayıcı uygulamaları için gRPC-Web ile REST'ten daha performanslı iletişim mümkündür.

Zayıf Yönleri:

  • Tarayıcı Desteği: Doğrudan tarayıcıdan çağrılamaz (gRPC-Web ile sınırlı destek).

  • Öğrenme Eğrisi: Protobuf, HTTP/2, streaming gibi kavramlar öğrenilmelidir.

  • Debug Zorluğu: Binary format, metin tabanlı JSON'a göre debug etmesi daha zordur (gRPCurl, gRPC UI gibi araçlar ile kısmen çözülür).

  • Cache: HTTP cache'den yararlanamaz.

5. Hangi Senaryoda Hangisi?

REST'i Seçin:

  • Genel amaçlı Web API'leri: Basit, kaynak odaklı API'ler (CRUD işlemleri).

  • Dışa Açık (Public) API'ler: Müşterilerin (istemcilerin) kolayca tüketmesi gereken API'ler.

  • Küçük ve Orta Ölçekli Projeler: Ekibin API tasarımı deneyimi sınırlıysa.

  • Tarayıcı Uygulamaları: Doğrudan JavaScript fetch ile tüketilecek API'ler.

  • Dokümantasyon ve Cache Ön Planda: Swagger/OpenAPI ve HTTP cache ihtiyacı varsa.

GraphQL'i Seçin:

  • Karmaşık ve Değişken Veri İhtiyaçları: Farklı istemciler (web, mobil) farklı veri setlerine ihtiyaç duyuyorsa.

  • Hızlı Frontend Geliştirme: Frontend ekiplerinin, backend değişikliği beklemeden yeni veri ihtiyaçlarını karşılaması gerekiyorsa.

  • BFF (Backend for Frontend) Pattern: Her istemci (web, mobil) için özel bir GraphQL API katmanı oluşturmak.

  • Çoklu Veri Kaynakları: Birden fazla mikroservis veya veritabanını tek bir API'de birleştirmek (federation).

gRPC'yi Seçin:

  • Yüksek Performanslı Mikroservis İletişimi: Servisler arası (internal) iletişimde düşük gecikme ve yüksek verim gerekiyorsa.

  • Gerçek Zamanlı Uygulamalar: Oyun, finansal veri akışı, canlı sohbet gibi streaming ihtiyaçları.

  • Çoklu Dil Ortamları: Farklı dillerde yazılmış servisler arasında güçlü tipli (type-safe) iletişim gerekiyorsa.

  • Mobil ve IoT: Bant genişliğinin ve pil ömrünün kritik olduğu cihazlar.

  • Düşük Gecikme Gereksinimleri: Milisaniye seviyesinde yanıt süresi gerekiyorsa.

Hibrit Yaklaşım:
Çoğu projede, üç teknolojinin kombinasyonu kullanılır:

  • Dış API'ler: REST (Müşteriler için kolaylık).

  • İç Servis İletişimi: gRPC (Performans ve tip güvenliği).

  • BFF Katmanı: GraphQL (Her istemci için özel veri birleştirme).

6. .NET Ekosisteminde Uygulama

REST (ASP.NET Core Web API):

csharp

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id}")]
    public async Task<ActionResult<Product>> GetProduct(int id)
    {
        var product = await _context.Products.FindAsync(id);
        if (product == null)
            return NotFound();
        return Ok(product);
    }
}

GraphQL (Hot Chocolate):

csharp

public class Query
{
    [UseDbContext(typeof(AppDbContext))]
    public async Task<IEnumerable<Product>> GetProducts([ScopedService] AppDbContext context)
    {
        return await context.Products.ToListAsync();
    }
}

gRPC (.NET):

protobuf

// product.proto
service ProductService {
    rpc GetProduct (ProductRequest) returns (ProductResponse);
}

csharp

public class ProductService : ProductService.ProductServiceBase
{
    public override async Task<ProductResponse> GetProduct(ProductRequest request, ServerCallContext context)
    {
        var product = await _context.Products.FindAsync(request.Id);
        return new ProductResponse { Id = product.Id, Name = product.Name };
    }
}

7. Performans Karşılaştırması (Gerçek Dünya)

Kriter REST (JSON) GraphQL (JSON) gRPC (Protobuf)
Serileştirme Hızı Orta Orta Çok Hızlı
Bant Genişliği Kullanımı Yüksek Orta (sorguya bağlı) Düşük
Gecikme (Latency) Orta Orta Düşük
CPU Kullanımı Orta Orta (parse) Düşük

Sonuç: gRPC, hem hız hem de bant genişliği açısından açık ara liderdir. REST ve GraphQL arasındaki fark, sorgu karmaşıklığına bağlı olarak değişir.

Sonuç:

REST, GraphQL ve gRPC arasındaki seçim, "en iyi" değil, "en uygun" olanı bulmaktır. REST, olgunluğu ve basitliği ile genel amaçlı API'ler için hala en yaygın tercihtir. GraphQL, istemci esnekliği ve hızlı geliştirme ihtiyaçları için güçlü bir araçtır. gRPC ise, yüksek performans ve düşük gecikme gerektiren iç servis iletişiminde tartışmasız liderdir.

Size Tavsiyem:

  • Projenizin gereksinimlerini netleştirin (istenen veri esnekliği, gecikme toleransı, ekip deneyimi).

  • Birden fazla teknolojiyi birlikte kullanmaktan çekinmeyin (hibrit yaklaşım).

  • .NET ekosisteminde her üç teknoloji için de olgun araçlar mevcuttur (ASP.NET Core, Hot Chocolate, gRPC for .NET).

Tüm yazılar