Microsoft YARP (Yet Another Reverse Proxy) Nedir? Ne için kullanılır?

Herkese selamlar. Bugün microsoft YARP kütüphanesine öğretici bir bakış atacağız.

Mikroservis işlerinde uzun süre Ocelot kullandım; sonra YARP (Yet Another Reverse Proxy) karşıma çıktı. “Microsoft ekosistemine bu kadar yakın bir gateway kütüphanesi nasıl hissettirir?” merakıyla araştırdım ve bir PoC yaptım. Notlarımı; kurulumdan ilk rotaya, oradan da birkaç “neden YARP?” noktasına kadar sizinle paylaşmak istiyorum. Hedefim, yazı bittiğinde çalışan bir YARP gateway’iniz ve “ileride neleri genişletebilirim?” diye düşünebileceğiniz bir yol haritanız olsun. YARP’ın Microsoft tarafından kütüphane (library) olarak tasarlandığını, ASP.NET Core pipeline’ına doğal biçimde oturduğunu bilmek, yazının geri kalanı için iyi bir başlangıç notu.

Sorun Tanımı

Mikroservisler çoğaldıkça, istemcinin her servise ayrı ayrı gitmesi yönlendirme, kimlik doğrulama, yetkilendirme, hız sınırlama (rate limit), CORS, log/trace gibi yatay sorumlulukları her servise tek tek dağıtıyor. Bu hem tekrar hem de tutarsızlık riski demek. API Gateway bu noktada tek giriş noktası olup trafiği doğru servislere yönlendirirken, güvenlik ve trafik politikalarını merkezileştirir; performans ve güvenilirlik için önbellekleme, eşzamanlı istek yönetimi, hatta protokol dönüşümleri gibi işleri de üstlenebilir.

YARP Nedir?

YARP, .NET için geliştirilmiş, yüksek özelleştirilebilir bir reverse proxy/gateway kütüphanesi. “Kutudan çıkan ürün” gibi değil; ASP.NET Core uygulamanıza eklediğiniz birkaç satır ile AddReverseProxy → LoadFromConfig → MapReverseProxy akışında ayağa kalkıyor. Bu yaklaşım, .NET’in kimlik doğrulama/ yetkilendirme, oran sınırlama, middleware zinciri gibi bileşenleriyle doğal entegrasyon sağlıyor. YARP’ın öne çıkanları:

• Konfigürasyon esnekliği: Routes/Clusters’ı dosyadan veya herhangi bir IConfiguration kaynağından yükleyebilme (değişiklikleri yeniden başlatmadan algılama).
• Transform’lar: Path, query, header, HTTP metodu/sürümü gibi alanlarda istek/yanıtı manipüle edebilme (JSON’dan ya da kodla).
• Yük dengeleme + oturum bağlılığı: Yerleşik algoritmalar ve session affinity (sticky) seçenekleri.

Nerede Kullanılır?

• Tek giriş noktası (entrypoint) & yönlendirme: İstemciler mikroservisleri tek bir kapıdan görür; gateway doğru clustera iletir.
• Kimlik doğrulama / yetkilendirme merkezî yönetimi: JWT doğrulama, rol/policy kararları gateway’de çözülür; servisler sade kalır. (Duende BFF ile YARP entegrasyonu, token ve anti-forgery gibi güvenlik adımlarını birleştirir.)
• Rate limiting & trafik kontrolü: Aşırı yük/istismar riskine karşı oran/ kota uygulama; IP veya anahtar bazlı politikalar.
• Transform’lar (gerçek hayat sihirleri): /api/orders/* → /orders/* ön ekini kırpma; X-Correlation-Id ekleme; sorgu parametreleriyle dil/kültür dayatma; gerekirse HTTP metodunu/versiyonunu ayarlama.
• Yük dengeleme & session affinity: Round-robin, least-requests, power-of-two gibi stratejiler; stateful parçalarda “aynı kullanıcı → aynı node”
• Dinamik konfigürasyon: JSON ile başlayıp proje büyüdükçe veritabanı / service discovery tabanlı sağlayıcılara geçiş; değişikliklerin “hot-reload” gibi algılanması.
• Gözlemlenebilirlik & teşhis: Gateway katmanından log/trace/metrik toplayıp sorun analizi yapmak (ör. “hangi route eşleşti, hangi destination seçildi?”).
• Basit bir PoC için: AddReverseProxy → LoadFromConfig("ReverseProxy") → MapReverseProxy iskeletiyle başlayıp tek rota/tek cluster tanımlayın; sonra adım adım auth, rate limit, transform ve LB/affinity ekleyin.

Ocelot vs YARP (Kısa karşılaştırma)

• Ocelot: Hızlı başlamak, basit/orta düzey gateway ihtiyacı için hafif ve pratik.
• YARP: Microsoft ekosistemiyle sıkı entegre, kütüphane yaklaşımı sayesinde .NET middleware zinciriyle derin özelleştirme, gelişmiş transform’lar, yük dengeleme ve session affinity gibi konularda daha esnek.

Ne zaman hangisi?

• “Basitçe route etsin, hemen çalışsın” → Ocelot.
• “İnce ayar yapacağım, pipeline’a gömeceğim, LB/affinity/transformları kurcalayacağım” → YARP. Karşılaştırma yazılarının da genel fikri bu yönde.

Hızlı Başlangıç (YARP)

Hedef: 10 dakikada çalışan bir gateway. Mantık: AddReverseProxy → LoadFromConfig → MapReverseProxy. YARP bir kütüphane; ASP.NET Core uygulamana eklenip pipeline’ın parçası olur.

1) Proje + paket

dotnet new web -n YarpGateway
cd YarpGateway
dotnet add package Yarp.ReverseProxy

2) Program.cs (en minimal)

var builder = WebApplication.CreateBuilder(args);
builder.Services
    .AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));
var app = builder.Build();
app.MapReverseProxy();
app.Run();

**appsettings.json (Routes & Clusters)**

{
  "ReverseProxy": {
    "Routes": {
      "products-route": {
        "ClusterId": "products",
        "Match": { "Path": "/products/{**catch-all}" },
        "Transforms": [ { "PathPattern": "{**catch-all}" } ]
      },
      "orders-route": {
        "ClusterId": "orders",
        "Match": { "Path": "/orders/{**catch-all}" },
        "Transforms": [ { "PathPattern": "{**catch-all}" } ]
      }
    },
    "Clusters": {
      "products": {
        "Destinations": { "d1": { "Address": "https://localhost:5001/" } }
      },
      "orders": {
        "Destinations": { "d1": { "Address": "https://localhost:5002/" } }
      }
    }
  }
}

Güvenlik & Rate Limiting (gateway’de merkezî yönetim)

Neden gateway’de? Servisler sade kalsın; kimlik/doğrulama (JWT), yetkilendirme (policy/role), rate-limit politikaları tek noktadan yönetilsin. BFF yaklaşımında Duende BFF + YARP entegrasyonu; token yönetimi ve anti-forgery gibi konularda hazır uzatmalar getirir.

Örnek (JWT + Policy + .NET RateLimiter):

builder.Services.AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", o =>
    {
        o.Authority = "https://identity.example.com";
        o.Audience  = "gateway";
        o.RequireHttpsMetadata = true;
    });
builder.Services.AddAuthorization(o =>
{
    o.AddPolicy("api", p => p.RequireAuthenticatedUser());
});
builder.Services.AddRateLimiter(o =>
{
    o.AddFixedWindowLimiter("fixed", opt =>
    {
        opt.PermitLimit = 100;                // 1 dakikada 100 istek
        opt.Window = TimeSpan.FromMinutes(1);
        opt.QueueLimit = 0;
    });
});
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.UseRateLimiter();
app.MapReverseProxy()
   .RequireAuthorization("api")
   .RequireRateLimiting("fixed");
app.Run();

YARP, proxy’lemeden önce ASP.NET Core pipeline’ındaki middleware’leri çalıştırır; yani authenticate/authorize/limit akışları doğal olarak işler. BFF ile birlikte kullanırken YARP uzantıları mevcuttur.

Load Balancing & Session Affinity (Trafiği Akıllıca Ve Mantıklı Dağıt)

YARP; PowerOfTwoChoices (varsayılan), LeastRequests, RoundRobin, Random, FirstAlphabetical gibi politikalarla trafiği dağıtır. Session Affinity (sticky) ile aynı kullanıcının isteklerini aynı hedefe sabitleyebilirsin (stateful parçalar için kritik)

Örnek cluster konfigürasyonu:

"Clusters": {
  "orders": {
    "LoadBalancingPolicy": "RoundRobin",
    "SessionAffinity": {
      "Enabled": true,
      "Policy": "Cookie",
      "FailurePolicy": "Redistribute"
    },
    "Destinations": {
      "n1": { "Address": "https://10.0.0.11:6001/" },
      "n2": { "Address": "https://10.0.0.12:6001/" }
    }
  }
}

Ne zaman sticky?

• Kullanıcıya özel cache/sunum varsa, session verisi paylaşılamıyorsa veya aynı node’da kalmak performans kazandırıyorsa.
• Affinity açtığında health checks, timeout/retry ile birlikte düşün; node düşerse kullanıcı sorunsuz başka node’a yönlendirilsin.

Transform’lar (Gerçek hayatta küçük sihirler)

Ne işe yarar? İstek/yanıt üzerinde path, query, header, HTTP metodu/sürümü gibi alanları değiştirebilirsin. Böylece /api/orders/* çağrısını arkada /orders/* olarak iletmek, X-Correlation-Id eklemek, dil parametresi zorlamak gibi işler gateway katmanında çözülür. Transform’lar JSON konfig ile de, kodla da tanımlanabilir ve çoğu durumda yeniden başlatmadan uygulanabilir.

Config ile örnek (prefix kırpma + header ekleme):

{
  "ReverseProxy": {
    "Routes": {
      "orders-route": {
        "ClusterId": "orders",
        "Match": { "Path": "/api/orders/{**catch-all}" },
        "Transforms": [
          { "PathRemovePrefix": "/api" },
          { "RequestHeader": "X-Gateway", "Set": "YARP" }
        ]
      }
    }
  }
}

Kodla şartlı transform (örnek):

builder.Services.AddReverseProxy()
  .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"))
  .AddTransforms(builderCtx =>
  {
      builderCtx.AddRequestTransform(ctx =>
      {
          ctx.ProxyRequest.Headers.Remove("Server");
          ctx.ProxyRequest.Headers.Add("X-Gateway", "YARP");
          return ValueTask.CompletedTask;
      });
  });

Dinamik Konfigürasyon (JSON → çoklu kaynaklar → filtreler)

Neden? Başlangıçta appsettings.json yeterli. Sistem büyüyünce birden çok kaynaktan (dosya, environment, InMemory, hatta DB/discovery) yükleme ve canlı yeniden yükleme (reload) ihtiyacı doğuyor. YARP, LoadFromConfig’i birden çok kez çağırarak farklı IConfiguration bölümlerinden yüklemeyi destekliyor; ayrıca Configuration Filters ile ham girdiyi uygulanmadan önce değiştirebiliyorsun (ör. tüm rotalara ortak header, ortak timeout).

Çoklu kaynak fikri:

builder.Services.AddReverseProxy()
  .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"))
  .LoadFromConfig(builder.Configuration.GetSection("ReverseProxyOverrides"));

Gözlemlenebilirlik & Teşhis (Prod Öncesi!)

İlk adım log seviyelerini açmak. YARP, ASP.NET Core middleware olarak çalıştığı için hem YARP hem ASP.NET loglarını etkinleştirmen gerekir. Resmî teşhis kılavuzu, “hangi route eşleşti / hangi destination seçildi / neden retry oldu” gibi sorulara hızlıca ışık tutan ayarları adım adım anlatıyor. OpenTelemetry ile trace/metrik de ekleyebilirsin; Azure App Service gibi ortamların kendi diagnostic logs imkânlarını da kullan.

Anti-Pattern’ler (Sık yapılan hatalar)

• Gateway’i tek nokta darboğaza çevirmek: Ölçeklendirmeyi ve health-based routing’i ihmal etmek (ölçeklendir, health check uygula).
• Aşırı transform: Ağır iş kurallarını gateway’e yığmak; performans ve okunabilirliği düşürür. Transform’ları hafif tut.
• Çifte auth: Hem gateway hem servislerde karmaşık ve çelişkili kurallar; mümkünse kararları gateway’de merkezîleştir.
• Affinity’yi yanlış konumda açmak: State paylaşımı mümkünken gereksiz sticky; veya açıp failure policy düşünmemek. (Varsayılan HashCookie, fallback stratejilerine dikkat.)

Benim Yolculuğum & Sonuç

YARP’ı merak ettim, küçük bir PoC ile başladım. Önce tek rota–tek cluster çalıştırdım; “çalışıyor mu?” sorusunu net yanıtladım. Sonra ufak dokunuşlar: sadece prefix kırpma (path temizliği), ardından kimlik doğrulama ve basit bir policy’yi gateway’e aldım. Son adımda iki hedef ekleyip trafiği dengeli dağıttım. Küçük adımlar, net kontroller.

Benim gözlemlerim şu şekilde: Mikroservisleri tek kapıdan geçirmek istiyorsanız, YARP esnek; Ocelot ise hızlı başlangıç için hâlâ çok güçlü.

Mikroservislerinizi daha düzenli, güvenli ve yönetilebilir kılmak istiyorsanız, bu yol denemeye değer. Bu yazıyı gateway’e ilk adımı atmak isteyenler için kısa bir rehber olarak hazırladım. Kendi deneyimlerinizi, yaşadığınız sorunları ve çözümleri paylaşmak isterseniz yorumlara beklerim. Okuduğunuz için teşekkürler! 😊

Kaynakça

• .NET Core: API Gateway Nedir? YARP Nedir? YARP ile API Gateway — DevOps Türkiye (Murat Dinç)
• .NET Core ile YARP Kullanımı — Salimcan Karadeniz
• Implementing an API Gateway for Microservices with YARP — Milan Jovanovic

Microsoft Learn (resmî dokümantasyon):

• YARP Overview
• Getting Started with YARP
• Configuration Files
• Configuration Filters
• Request & Response Transforms
• Request Transforms (detaylı)
• Load Balancing
• Session Affinity
• Diagnosing YARP-based proxies
• Rate Limiting (YARP)

Duende BFF (YARP entegrasyonu):

• Duende BFF — YARP extensions
• Duende BFF — Proxying Remote APIs