BFF — Backend for Frontend
Önce şunu oku: Mikroservis Katmanları — İstek Nereden Geçiyor
30 saniyede özet
BFF, tek bir ekrana (mobil, web) özel bir arka uçtur ve onu BFF yapan şey teknoloji değil, sahibidir: o ekranın ekibi. Herkesin ortak kullandığı bir BFF, adı değişmiş sıradan bir API'dir.
Bir düğünde her masaya atanmış bir garson, o masanın alerjisini ve çocuk menüsünü bilir. Bütün salona tek garson bakarsa kimsenin özel isteği takip edilemez.
-
Bayt: Mobil ekibi ekrana ne göstereceğini değiştirmek istiyor, ama her seferinde başka bir ekipten izin bekliyor.
-
Sen: Peki kendi arka uçları olsa?
-
Bayt: İşte BFF. Ama onu BFF yapan kullandığı çatı değil, kimin sahip olduğu.
-
Bayt: Masaya atanmış garson, masanın ne istediğini herkesten iyi bilir!
Mobil uygulamanın ekibi, ekrana ne göstereceğini başka bir ekipten izin almadan değiştirmek istiyor. Oysa BFFBackend for Frontend: tek bir istemci türüne (mobil, web, TV) hizmet eden, o istemcinin ekranlarına biçilmiş yanıt döndüren backend.Sahipliği istemci ekibindedir. Genel amaçlı bir API herkese yetecek kadar veri döndürmek zorundayken BFF tam gerekeni döndürür; bedeli, her istemci türü için ayrı bir servis bakmaktır.Sözlükte gör →’i BFF yapan şey kullandığı çatı değil, kimin sahip olduğu.
Sahiplik olmadan BFF olmaz
BFF’in tek üstünlüğü taraflı olabilmesi. Mobil ekranların ne istediğini bilir ve tam onu döndürür; genel amaçlı bir API ise herkese yetecek kadar döndürmek zorundadır.
Bu taraflılık ancak sahiplik istemci ekibindeyse sürer. Platform ekibinin baktığı bir BFF’de her ekran değişikliği yine başka bir ekibin kuyruğunda bekler — yani BFF’i kurma sebebin ortadan kalkar.
Sayı kuralı basit: istemci türü başına bir BFF. Ekran başına değil — o zaman yüzlerce servis bakarsın; tüm istemcilere tek tane de değil — o zaman BFF olmaktan çıkar.
Kafam karıştı, daha basit anlat
BFF, bir ekranın kişisel garsonudur: ne istediğini bilir ve tam onu getirir. Garsonu o ekranı yapan ekip yönetmezse, her istek başka bir ekibin sırasında bekler.
Bir backend'i BFF yapan şey nedir?
BFF ile genel amaçlı bir API arasındaki temel fark nedir?
BFF’e ne girer, ne girmez?
| BFF’e girer | BFF’e girmez |
|---|---|
| Beş servisin yanıtını tek yanıtta birleştirmek | İndirim tutarını hesaplamak |
| Mobilin kullanmadığı alanları çıkarmak | Siparişin iptal edilebilir olup olmadığı |
| Tarih ve para biçimini istemcinin beklediği şekle çevirmek | Stok düşme kuralı |
| Hangi bağımlılığın zorunlu hangisinin isteğe bağlı olduğu | Fiyatın nasıl belirlendiği |
Ayıran soru tek: aynı kural ikinci bir istemcide de geçerli mi? Geçerliyse orası BFF değil, domain servisidir. Geçerli değilse ve yalnızca bu ekranların derdiyse BFF’e aittir.
Kafam karıştı, daha basit anlat
Bir kural ikinci bir istemcide de geçerliyse, BFF’in değil asıl servisin işidir. BFF’e yalnızca o ekrana özel düzenlemeler girer.
Bir mantığın BFF'e mi domain servisine mi ait olduğunu nasıl anlarsın?
Satır satır: bir servis düştüğünde
Bir BFF’in en kritik kararı birleştirme değil, her bağımlılık için zorunlu mu isteğe bağlı mı sorusuna verdiği cevap.
Beş bağımlılığın her biri %99,9 ise, hepsini zorunlu sayan sayfanın kullanılabilirliği kaç olur? Cevabı göster
Yaklaşık %99,5. Kullanılabilirlik toplanmaz, çarpılır: 0,999⁵ ≈ 0,995. Ayda yaklaşık 3,6 saat kesinti demek — ve bunun büyük kısmı yorumlar gibi isteğe bağlı bir servisten gelir.
Adım adım oku
- Mobil BFF, tek bir ekrana atanmış garson gibidir.
- Sayfa için beş servisten veri toplar: ürün, fiyat, stok, kargo ve yorumlar.
- Yorum servisi çöker.
- Yorumlar isteğe bağlı sayıldığı için sayfa yine açılır; yalnızca yorum kutusu boş gelir.
Zorunlu ve isteğe bağlı ayrımı
// istemciye 3 sn sonra timeout dönüyor// BFF'in her servis çağrısı: 2 sn timeout, 1 retry var product = catalogue.get(id);var price = pricing.get(id);var reviews = reviewService.get(id); return new PageDto(product.join(), price.join(), reviews.join());Debug
zorunlu Ürün olmadan sayfa diye bir şey yok. Bu bağımlılık gerçekten zorunlu.
- karar
- = zorunlu
Sol/sağ ok tuşlarıyla da gezebilirsin.
Buna timeout bütçesiBir zincirdeki timeout değerlerinin içten dışa artacak şekilde bölünmesi. Dıştaki içtekinden küçükse çağıran vazgeçer ama iş devam eder.Sözlükte gör → denir: aşağı indikçe süre küçülmeli. Retry’ı da bütçeye dahil etmen gerekir, çünkü retry süreyi katlar.
Aynı kararları bir mobil bankacılık ana ekranında görelim. Hesaplar şart, kart özeti ve döviz kurları olmasa da olur; bak ekran bu ayrımla nasıl ayakta kalıyor.
Derinleş · Mobil bankacılık ana ekranı: hesaplar şart, gerisi olmasa da olur 3 dosya · ~101 satır · ilk okumada atlayabilirsin
Beş bağımlılığın her biri %99,9 kullanılabilir. Hepsini zorunlu sayan sayfanın kullanılabilirliği ne olur?
Her sorumluluğu, BFF'e mi domain servisine mi ait olduğuna göre ayır.
Kendin gör
Aynı ürün sayfası BFF’i. Servislerin sağlığını, timeout’u, retry’ı, paralel çağrıyı ve isteğe bağlı servis için politikayı değiştir. Çubuklardaki dikey çizgi, istemcinin vazgeçtiği üçüncü saniye.
BFF fan-out — bir servis düşünce sayfa ne olur?
Tohum 316767// her çağrı: 2000 ms timeout, 1 retry; istemci 3000 ms beklervar product = catalogue.get(id); // hepsi aynı anda başlarvar price = pricing.get(id);var reviews = reviewService.get(id); return new PageDto(product.join(), price.join(), reviews.join());- cataloguezorunlu
- pricingzorunlu
- reviewsisteğe bağlı
- | istemcinin sınırı: 3000 ms
Şu an ne oldu?
Ürün sayfası isteği BFF'e geldi
BFF üç servisi aynı anda çağırıyor. İstemci 3 saniye bekleyecek.
Görevler0/3
Yalnızca yorum servisi düşükken bütün sayfayı düşüraçık
İpucu
Varsayılan ayarlarla oynat: ürün ve fiyat sağlıklı, yorumlar düşük, politika "sayfa hata dönsün".
Aynı durumda sayfayı yorumlar olmadan ayakta tutaçık
İpucu
Politikayı değiştir: isteğe bağlı servis boş liste dönebilir.
Yorum servisi YAVAŞKEN bile sayfa istemcinin 3 saniyesine sığsınaçık
İpucu
Yavaş bir servis, timeout × deneme kadar bekletir. İkisinin çarpımı 3 saniyenin altında kalmalı.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Yorum servisi düşük ve bütün sayfa 502 dönüyor.
- Politikayı “Yorumlar boş gelsin” yap. Aynı arıza artık kısmi bir sayfa.
- Yorum servisini “Yavaş” yap. Timeout ve retry, istemcinin üç saniyelik bütçesini aşıyor.
- Timeout’u 1 saniyeye indir. Sayfa yine zamanında ve kısmi dönüyor.
- Paralel çağrıyı kapat. Süre, en yavaş çağrı yerine üç çağrının toplamı oluyor.
Simülatörde yorum servisi yavaş, politika "yorumlar boş gelsin", çağrı başına timeout 2 sn ve 1 retry var. İstemci 3 sn bekliyor. Ne olur?
Tuzaklar
BFF’e iş kuralı sızması “sadece şu küçük kontrol” diye başlar. Altı ay sonra indirim mantığının bir kısmı BFF’te, bir kısmı domain servisinde olur ve ikisi ayrışır. Ölçüt hep aynı: ikinci bir istemcide de geçerli mi?
Ekran başına BFF. Sahiplik doğru ama sayı yanlış. Her ekran için ayrı bir servis, bakım yükünü sağladığı esnekliğin çok üstüne çıkarır.
BFF’i servisler arası ortak çağrı noktası yapmak. Domain servisleri birbirini BFF üzerinden çağırmaya başlarsa BFF kritik yol hâline gelir ve elinde dağıtık monolitServisleri ayırıp bağımsızlığı kazanamamış sistem: ortak veritabanı, koordineli deploy, senkron zincirler.En kötü bileşim — monolitin kolaylığını kaybeder, mikroservisin faydasını almazsın. Teşhis sorusu tek: bir servisi tek başına deploy edebiliyor musun?Sözlükte gör → kalır. BFF yalnızca kendi istemcisine bakar.
Kendini sına
Bir BFF'i BFF yapan, kullandığı teknoloji değil sahipliğidir.
Katalog servisi yanıt vermiyor. İstemci ne zaman ne görür?
Aklında kalacak üç şey
- 1 BFF'i BFF yapan şey sahipliktir. Ekranın ekibi sahip değilse ortada ikinci bir genel amaçlı API vardır.
- 2 BFF'e ekranı hazırlama mantığı girer, iş kuralı girmez. Aynı kural başka bir ekranda da geçerliyse o kural BFF'e ait değildir.
- 3 Beş servisi sorgusuz birleştiren bir BFF, birinin düşmesiyle bütün ekranı düşürür. Her servis için 'zorunlu mu, olmasa da olur mu?' kararı verilmelidir.
5 kart sonraki derste seni bekliyor
Bu dersin üstüne kurulanlar
Bunlar bu dersi temel alıyor; hazır olduğunda devam edebilirsin.