BFF ve API Composition
Backend-for-Frontend (BFF), her istemci türünün ihtiyaçlarına göre optimize edilmiş bir backend katmanıdır. API composition ise birden fazla servisten veriyi toplayıp tek bir istemci response'una dönüştürür. Bu katman domain sahibi olmamalı; istemciye uygun orkestrasyon sağlamalıdır.
Hızlı Karar
| Durum | Yaklaşım | Dikkat |
|---|---|---|
| Web ve mobil response ihtiyaçları farklı | Ayrı BFF | Ortak domain kuralını çoğaltma |
| Bir ekran 3+ servise ihtiyaç duyuyor | Composition | Partial failure ve timeout tasarla |
| Sadece route/auth/rate limit gerekiyor | API Gateway | İş orkestrasyonunu gateway'e koyma |
| Aynı aggregation birçok client'ta kullanılıyor | Domain/query service | BFF'yi ortak platforma dönüştürme |
Üretim Kontrol Listesi
- Problem: BFF hangi client deneyimini veya network maliyetini iyileştiriyor?
- Çözüm: Downstream fan-out, timeout, auth propagation, cache ve response contract net mi?
- Trade-off: Daha az round-trip ve daha iyi payload sağlanır; yeni deployable service ve ownership doğar.
- Hata durumu: Partial response, stale data, one dependency timeout ve client-specific fallback tanımlı mı?
- Ölçüm: Fan-out sayısı, aggregate p95, downstream contribution, payload size ve error rate izlenmeli.
- Güvenlik/maliyet: BFF client token'ını gereksiz servislere taşımamalı; fan-out connection ve compute maliyetini artırır.
BFF ile Gateway Ayrımı
Gateway ortak ağ politikalarını uygular: TLS termination, route, authn, rate limit, correlation ID ve basit transformation. BFF ise client-specific response modelini ve çağrı sırasını bilir.
Gateway'e domain aggregation eklemek merkezi değişiklik ve tek hata noktası yaratır. BFF de domain kuralını kendi içinde kopyalamamalı; source of truth downstream service olmalıdır.
API Composition
Composition akışı şu sınırları açıkça taşır:
- Client auth ve tenant context doğrulanır.
- Bağımsız çağrılar bounded parallelism ile başlatılır.
- Her downstream için deadline, retry ve circuit policy uygulanır.
- Response modelinde required ve optional parçalar ayrılır.
- Partial failure, cache staleness veya fallback istemciye açık bir metadata ile bildirilir.
Örneğin ana sipariş bilgisi zorunlu, önerilen ürünler opsiyonelse öneri servisi timeout olduğunda sipariş response'u başarısız olmamalıdır. Bunun tersi durumda 200 dönüp eksik zorunlu veriyi gizlemek sözleşme ihlalidir.
Cache, Auth ve Ownership
BFF response cache'i user, tenant, locale ve permission scope ile anahtarlanmalı; kişisel veri shared cache'e yazılmamalıdır. Downstream authorization yeniden yapılmalıdır; BFF'den gelen header'ı güvenilir kimlik kanıtı sayma.
Her BFF'nin sahibi, deploy bağımsızlığı, SLO'su ve downstream dependency budget'ı olmalı. Çok fazla BFF, ortak dönüşüm ve tekrar eden auth koduyla yeni bir monolith oluşturabilir.
Ne Zaman Kullanılmamalı?
Tek bir downstream çağrısını proxy etmek, yalnızca payload alanını yeniden adlandırmak veya domain kurallarını gizlemek için BFF eklemek gereksizdir. Önce mevcut API'nin pagination, field selection, caching ve client SDK seçeneklerini değerlendir.