“BFF vs API Gateway”, mikro hizmet mimarisinde sık karıştırılan iki desendir. Diyagramda benzer görünürler: ikisi de istemcilerin önünde durur, isteği alır ve arka uçlara iletir. Ancak aynı işi yapmazlar. API ağ geçidi ortak platform politikalarını uygular; BFF ise belirli bir ön ucun ihtiyaç duyduğu API şeklini üretir.
Bunlar rakip değildir. Bir Backend for Frontend (BFF), API ağ geçidinin yerine geçmez; çoğu mimaride ağ geçidinin arkasında veya yanında çalışır.
Bu yazıda iki deseni uygulama açısından ayıracağız: hangi sorumluluk nereye gider, ne zaman yalnızca gateway yeterlidir, ne zaman BFF eklenir ve ikisini karıştırınca hangi problemler ortaya çıkar.
API Ağ Geçidi Nedir?
Bir API ağ geçidi, istemciler ile arka uç servisleriniz arasında merkezi giriş noktasıdır.
Temel görevi, tüm istemciler için aynı olması gereken çapraz kesen sorumlulukları tek yerde uygulamaktır:
-
Yönlendirme:
/ordersisteğini order servisine,/productsisteğini product servisine gönderme. - Kimlik doğrulama ve yetkilendirme: token doğrulama, yetkisiz istekleri reddetme.
- Rate limiting / throttling: servisleri aşırı yükten ve kötüye kullanımdan koruma.
- Gözlemlenebilirlik: log, metric ve trace üretme.
- TLS sonlandırma, cache ve istek dönüşümü: ortak altyapı davranışlarını merkezi yönetme.
Örnek istek akışı:
Client
↓
API Gateway
├─ Auth kontrolü
├─ Rate limit kontrolü
├─ Logging / tracing
↓
Product Service
API ağ geçidinin belirleyici özelliği şudur: istemciden bağımsızdır. Mobil uygulama, web SPA veya üçüncü taraf entegrasyon aynı gateway’den geçer ve aynı platform politikalarına tabi olur.
Bu yüzden gateway genellikle platform veya altyapı ekibi tarafından yönetilir. Daha geniş API platformu bağlamı için API yönetimi ve API ağ geçidi karşılaştırmasına bakabilirsiniz.
Backend for Frontend (BFF) Nedir?
Backend for Frontend, Sam Newman tarafından popülerleştirilen bir desendir. Fikir basittir: her kullanıcı deneyimi için ona özel bir arka uç oluşturursunuz.
Örneğin:
Web App → Web BFF → Microservices
Mobile App → Mobile BFF → Microservices
Partner UI → Partner BFF → Microservices
BFF’nin amacı genel amaçlı bir API sunmak değildir. Belirli bir ön ucun ihtiyaç duyduğu veriyi toplamak, sadeleştirmek ve uygun biçimde döndürmektir.
Sam Newman’ın pratik kuralı:
Bir deneyim, bir BFF.
Yani gerçekten farklı kullanıcı deneyimleri ayrı BFF alır. Ancak aynı ekip tarafından geliştirilen ve benzer ihtiyaçları olan iOS ve Android istemcileri tek bir mobil BFF paylaşabilir.
BFF genellikle ön uç ekibine aittir. Çünkü BFF, kullanıcı arayüzünün veri ihtiyacına sıkı bağlıdır. Ön uç değiştikçe BFF de hızlı değişir.
BFF Pratikte Ne Yapar?
Bir BFF’nin tipik işleri şunlardır:
1. Veri toplama
Mobil ürün detay ekranı şu servislerden veri istiyor olabilir:
- Product Service
- Inventory Service
- Pricing Service
- Review Service
- Recommendation Service
Mobil istemcinin beş ayrı istek atması yerine BFF tek uç nokta sunar:
GET /mobile/product-detail/123
BFF içeride servisleri çağırır:
Mobile App
↓
Mobile BFF
├─ Product Service
├─ Inventory Service
├─ Pricing Service
├─ Review Service
└─ Recommendation Service
Sonra tek yanıt döndürür:
{
"id": "123",
"name": "Kablosuz Kulaklık",
"price": 1299,
"inStock": true,
"rating": 4.7,
"recommended": [
{
"id": "456",
"name": "Şarj Kutusu"
}
]
}
2. Veri kırpma
Arka uç servisi 40 alan döndürüyor olabilir, fakat mobil ekran yalnızca 5 alana ihtiyaç duyar.
BFF gereksiz alanları çıkarır:
{
"id": "123",
"name": "Kablosuz Kulaklık",
"price": 1299,
"inStock": true
}
Bu özellikle mobil ağlarda bant genişliği ve latency açısından önemlidir.
3. İstemciye özel biçimlendirme
Web uygulaması geniş ekran için detaylı veri isterken mobil uygulama daha sade veri isteyebilir.
Örneğin web BFF:
GET /web/dashboard
Mobil BFF:
GET /mobile/home-summary
İkisi aynı mikro servislerden beslense bile yanıt şekilleri farklı olabilir.
Bu yönüyle BFF, kişilikli bir API toplayıcısıdır: servis çağrılarını birleştirir, fakat bunu belirli bir ön uç için yapar.
BFF ve API Ağ Geçidi Nerede Örtüşür?
Karışıklık buradan gelir. İkisi de:
- istemci isteğini alır,
- arka uç servislerine yönlendirebilir,
- birden fazla servisi çağırabilir,
- yanıtı değiştirebilir.
Ancak fark niyet ve sahipliktedir.
| Sorumluluk | API Ağ Geçidi | BFF |
|---|---|---|
| Odak | Platform politikası | İstemci deneyimi |
| Sahiplik | Platform / altyapı ekibi | Ön uç ekibi |
| Kapsam | Tüm istemciler | Belirli bir istemci |
| Değişim ritmi | Daha stabil | Ön uçla birlikte hızlı değişir |
Pratik sınır şudur:
- Her istemci için aynıysa gateway’e koyun.
- Ön uca göre değişiyorsa BFF’ye koyun.
Örneğin:
Auth kontrolü → API Gateway
Rate limiting → API Gateway
Trace/log üretimi → API Gateway
Mobil payload şekli → Mobile BFF
Web dashboard modeli → Web BFF
Kimlik doğrulama veya rate limiting’i BFF’ye koyarsanız, her BFF’de aynı güvenlik mantığını tekrar yazarsınız. Bu da zamanla politika sapmasına neden olur.
BFF ve API Ağ Geçidi Birlikte Nasıl Çalışır?
Gerçek mikro hizmet sistemlerinde çoğu zaman ikisini birlikte kullanırsınız.
Tipik akış:
Mobile Client
↓
API Gateway
↓
Mobile BFF
↓
Microservices
Adım adım:
- Mobil istemci token ile istek gönderir.
- API gateway token’ı doğrular, rate limit uygular, log/trace üretir.
- Gateway isteği Mobile BFF’ye yönlendirir.
- Mobile BFF gerekli mikro servisleri çağırır.
- BFF mobil ekran için yanıtı şekillendirir.
- Yanıt gateway üzerinden istemciye döner.
Örnek:
GET /api/mobile/product-detail/123
Authorization: Bearer <token>
Gateway tarafında yapılacaklar:
- Token geçerli mi?
- Kullanıcının bu endpoint’e erişimi var mı?
- Rate limit aşıldı mı?
- Request trace ID oluşturuldu mu?
- İstek hangi BFF’ye yönlendirilecek?
BFF tarafında yapılacaklar:
- Product verisini al
- Stok bilgisini al
- Fiyat bilgisini al
- Mobil için gereksiz alanları çıkar
- Tek response oluştur
Bu katmanlama, gateway’in diğer altyapı katmanlarıyla ilişkisine benzer. Gateway bir yük dengeleyici değildir (API ağ geçidi vs yük dengeleyici); bir service mesh de değildir (hizmet ağı vs API ağ geçidi). Her katman ayrı bir problemi çözer.
Aynı prensip API liderliğindeki bağlantı yaklaşımında da geçerlidir: her katmana net bir sorumluluk verin.
Karar Tablosu: BFF vs API Ağ Geçidi
| Soru | API Ağ Geçidi | BFF |
|---|---|---|
| Kime ait? | Platform / altyapı ekibi | Onu tüketen ön uç ekibi |
| Kime hizmet eder? | Tüm istemcilere tekdüze | Tek bir belirli ön uca |
| Birincil görev | Auth, rate limit, routing, observability | İstemciye özel veri toplama ve şekillendirme |
| Kaç tane çalıştırılır? | Genellikle edge başına bir tane | Her farklı kullanıcı deneyimi için bir tane |
| Bağlılık | Gevşek, istemciden bağımsız | Sıkı, istemciye özel |
| Değişim sıklığı | Daha stabil | Ön uç yol haritasıyla birlikte hızlı |
| Ne koyulur? | Her istemci için aynı olanlar | Bir istemciye özel olanlar |
Bunu bir yönlendirme kuralı gibi düşünebilirsiniz:
Sorumluluk tüm istemciler için aynı mı?
Evet → API Gateway
Hayır → BFF
Ne Zaman API Ağ Geçidi Kullanmalı?
Aşağıdaki durumlarda API gateway kullanın:
- Birden fazla mikro servisiniz varsa.
- Dış dünyaya açılan birden fazla endpoint varsa.
- Auth, rate limit ve routing’i merkezi yönetmek istiyorsanız.
- Her servisin aynı güvenlik ve gözlemlenebilirlik kodunu tekrar etmesini istemiyorsanız.
- Partner veya üçüncü taraf entegrasyonlarınız varsa.
Çoğu mikro hizmet sisteminde gateway erken eklenmesi gereken bir katmandır.
Basit yapı:
Client → API Gateway → Services
Ne Zaman BFF Kullanmalı?
BFF şu durumlarda anlamlıdır:
- Web ve mobil istemcileriniz aynı servislerden farklı veri istiyor.
- Mobil istemci çok fazla network round-trip yapmak zorunda kalıyor.
- Genel amaçlı API, farklı ön uçların ihtiyaçları yüzünden karmaşıklaşıyor.
- Ön uç ekibi küçük veri şekli değişiklikleri için sürekli arka uç ekibini bekliyor.
- Paylaşılan API, istemciye özel alanlar ve parametrelerle şişiyor.
Örnek kötü sinyal:
GET /products/123?includeMobileFields=true&compact=true&hideRecommendations=false&webLayout=v2
Bu tip parametreler artıyorsa, istemciye özel bir BFF düşünme zamanı gelmiş olabilir.
Ne Zaman BFF Kullanmamalı?
BFF her zaman gerekli değildir.
Şu durumlarda atlayın:
- Tek bir istemciniz varsa.
- Tüm istemciler neredeyse aynı API çağrılarını yapıyorsa.
- Paylaşılan API mevcut ihtiyaçları temiz şekilde karşılıyorsa.
- Ek servis dağıtımı ve operasyon yükü istemiyorsanız.
- GraphQL gibi bir katman, istemcilerin ihtiyaç duyduğu alanları zaten seçmesine izin veriyorsa.
BFF eklemek şu maliyetleri getirir:
- Ek network hop.
- Dağıtılacak yeni servis.
- İzlenecek yeni log/metric.
- BFF’ler arasında olası kod tekrarı.
- Yeni API sözleşmeleri.
Bu yüzden BFF’yi, istemci farklılığı gerçek olduğunda ekleyin.
Yaygın Hatalar
1. Auth ve rate limiting’i BFF’ye koymak
Bu en yaygın hatadır.
Yanlış:
Client → Mobile BFF → Auth kontrolü → Services
Client → Web BFF → Auth kontrolü → Services
Doğru:
Client → API Gateway → Auth / rate limit → BFF → Services
Auth, rate limit ve gözlemlenebilirlik gibi çapraz kesen endişeler gateway’e aittir.
2. BFF’yi ikinci bir monolite çevirmek
BFF küçük ve belirli bir deneyime odaklı kalmalıdır.
BFF’ye şunları yığmayın:
- Ortak domain kuralları
- Tüm istemcilere ait iş mantığı
- Uzun yaşayan genel amaçlı servis davranışları
- Diğer ekiplerin de bağımlı olduğu merkezi API kuralları
Bunları eklerseniz BFF, kaldırmaya çalıştığınız genel amaçlı arka uca dönüşür.
3. Gateway’i BFF gibi kullanmak
Bazı ekipler istemciye özel dönüşümleri gateway konfigürasyonuna koyar.
Küçük ölçekte çalışabilir, ama zamanla şu probleme dönüşür:
Ön uç ekibi → Gateway değişikliği için platform ekibini bekler
Bu, BFF’nin çözmek istediği bağımlılığı geri getirir.
4. Tek istemci varken BFF oluşturmak
Yalnızca bir web uygulamanız varsa ve başka istemci yoksa, BFF erken optimizasyon olabilir.
Önce temiz bir API yayınlayın. İkinci ve gerçekten farklı istemci geldiğinde BFF ekleyin.
5. API sözleşmesini unutmak
Her gateway route ve her BFF endpoint bir API sunar.
Bu yüzden her biri için şunlar gerekir:
- Açık sözleşme
- Testler
- Mock ortamı
- Dokümantasyon
- Versiyonlama stratejisi
Aksi halde “ince BFF” dediğiniz katman, sadece onu yazan ekibin anlayabildiği kapalı bir kutuya dönüşür. Detay için API sözleşmesi nedir yazısına bakabilirsiniz.
Apidog Nereye Uyar?
Bir istek gateway’den, BFF’den veya ikisinden birden geçebilir. Fakat her durumda ortada bir API sözleşmesi vardır.
Apidog, bu sözleşmeleri tasarlamak, test etmek, mock’lamak ve belgelemek için kullanabileceğiniz çalışma alanıdır. API gateway veya BFF inşa etmez; bunların sunduğu API yüzeylerini yönetmenize yardımcı olur.
Pratik kullanım senaryoları:
Tasarım
BFF’nin döndüreceği birleşik yanıtı önce şema olarak modelleyin.
Örneğin:
{
"productId": "string",
"title": "string",
"price": "number",
"availability": "boolean",
"summary": "string"
}
Ardından ön uç ve arka uç ekiplerinin aynı sözleşmeye göre geliştirme yapması için OpenAPI çıktısı kullanın.
Mock
BFF henüz hazır değilken mobil ekip ekran geliştirmeye başlayabilir.
Mobile App → Apidog Mock → Beklenen BFF yanıtı
Bu, API-öncelikli geliştirme akışını destekler.
Test
Gateway arkasındaki gerçek endpoint’lere otomatik testler yazabilirsiniz:
- Token geçerli mi?
- Yetkisiz istek 401 dönüyor mu?
- Rate limit sonrası doğru hata dönüyor mu?
- BFF yanıtı beklenen şemaya uyuyor mu?
- Toplanan alanlar eksiksiz mi?
Dokümantasyon
Her BFF ve gateway route için etkileşimli dokümantasyon yayınlayın. Böylece tüketen ekipler implementasyon kodunu okumadan API sözleşmesini anlayabilir.
Mimari kararınız gateway, BFF veya ikisi birlikte olabilir. Değişmeyen şey API sözleşmesidir. Apidog bu sözleşmeyi görünür ve test edilebilir tutar.
BFF ve gateway sözleşmelerinizi arka uç kodu yazmadan önce tasarlamak ve mock’lamak için Apidog'u ücretsiz deneyin.
Sıkça Sorulan Sorular
BFF bir API ağ geçidi türü müdür?
Hayır. İkisi de yönlendirme ve toplama yapabilir, ancak sahiplik ve amaç farklıdır. API gateway merkezi platform katmanıdır; BFF belirli bir ön uç deneyimine göre tasarlanır.
BFF’yi API gateway olmadan kullanabilir miyim?
Evet, teknik olarak kullanabilirsiniz. Ancak ölçekli sistemlerde genellikle önerilmez. Gateway yoksa her BFF auth, rate limit ve gözlemlenebilirlik gibi ortak işleri tekrar uygulamak zorunda kalabilir.
Kaç tane BFF olmalı?
Sam Newman’ın “bir deneyim, bir BFF” kuralını uygulayın. Gerçekten farklı her kullanıcı deneyimi için ayrı BFF oluşturun. Benzer iOS ve Android istemcileri aynı ekip tarafından yönetiliyorsa ortak mobil BFF paylaşabilir.
BFF, API gateway’in yerini alır mı?
Hayır. Gateway kenarda tek tip politikaları uygular. BFF ise gateway’in arkasında belirli istemci için veriyi şekillendirir. Çoğu mikro hizmet sisteminde ikisi birlikte çalışır.
Ne zaman BFF oluşturmamalıyım?
Tüm istemciler benzer istekler yapıyorsa, yalnızca tek istemciniz varsa veya GraphQL gibi bir katman istemcilerin ihtiyaç duyduğu alanları seçmesini zaten sağlıyorsa BFF eklemeyin.
Kimlik doğrulama ve rate limiting nereye ait?
API gateway’e aittir. Bunlar tüm istemcilerde tek tip uygulanması gereken çapraz kesen sorumluluklardır. Bunları BFF’ye koymak tekrar ve politika sapması üretir.
Top comments (0)