Bir web uygulamasını büyütmeye başlayınca hep aynı dert kapıyı çalıyor. Web başka şey istiyor, iOS başka, Android bambaşka. Backend ekibi de bir noktada “bu API neden bu kadar şişti?” diye bakakalıyor — ve işte tam burada BFF devreye giriyor. Yani Backend for Frontend. Adından da anlaşılacağı gibi, her istemci türü için ayrı bir arayüz katmanı kuruyorsunuz; kulağa ekstra iş gibi geliyor, evet,. Doğru yerde kullanınca bayağı rahatlatıyor insanı.
Ben bu modeli ilk kez 2023’ün sonlarında, İstanbul’da küçük ama hırslı bir SaaS ekibinin toplantısında gördüm. O gün masa üstünde üç farklı ekran vardı: web paneli, mobil uygulama ve müşteri destek ekibinin kullandığı iç araç. Herkes aynı veriyi istiyordu. Ama herkesin istediği biçim farklıydı. Tam orada — o toplantı masasında — “tek API herkese uysun” yaklaşımının neden bazen patladığını çok net anladım.
BFF tam olarak ne yapıyor?
Düz anlatayım. BFF, ön taraftaki uygulamaların ihtiyacına göre veri topluyor, biçimlendiriyor ve geri veriyor. Tek başına kahraman değil — daha çok mutfakta tabak hazırlayan usta garson gibi düşünün, nasıl desem (ki bu çoğu kişinin gözünden kaçıyor). Arkadaki servislerden ürün bilgisi geliyor, stok geliyor, fiyat geliyor; BFF bunları alıp ön yüzün rahatlıkla sindireceği, sade bir hale getiriyor.
Ve işler burada ilginçleşiyor.
Bu modelin en sevdiğim tarafı şu: istemcilerle konuşurken gereksiz detayları dışarıda bırakabiliyor. Mobilde uzun açıklamalar, karmaşık ilişki alanları ya da yönetim paneline özel alanlar çoğu zaman zaten gerekmiyor ki. Mobil kullanıcıya ağır JSON dökmek yerine hafif. Net bir cevap vermek hem hız kazandırıyor hem de veri trafiğini ciddi ölçüde azaltıyor (ki bu çoğu kişinin gözünden kaçıyor)
Neden klasik yaklaşım yetmiyor?
Klasik modelde backend takımı herkesi memnun etmeye çalışıyor. Sonuç? Ortaya Frankenstein vari endpoint’ler çıkıyor. Bir endpoint var ama içinde beş farklı kullanım senaryosu gizli; kim neyi kırarsa artık şansınıza kalmış. Geçen yıl Ankara’daki bir ekipte buna yakın bir yapıyı test ettim — başlangıçta “tek servis kolay olur” denmişti, sonra frontend tarafı her sprint sonunda yeni alanlar isteyince endpoint şişti de şişti. Böyle böyle.
Şahsen, Buradaki mesele sadece teknik borç değil, ekip iletişimi de bozuluyor aynı zamanda. Frontend kendi hızında gitmek istiyor, backend ise veri bütünlüğünü korumaya çalışıyor. BFF ikisinin tam arasına oturup tansiyonu düşürüyor desem yeridir.
BFF mimarisinin mantığı nasıl kuruluyor?
En basit haliyle yapı şöyle işliyor: kullanıcı arayüzü istek atar, o istek ilgili BFF katmanına gelir, BFF gerekirse birkaç mikro servise paralel çağrı yapar (en azından benim deneyimim böyle). Sonucu tek bir cevap halinde döner. Bu kadar mı? Kağıt üstünde evet. Pratikte ise caching, hata yönetimi ve kimlik doğrulama devreye girince iş biraz daha renkleniyor tabi.
| Katman | Görev | Tipik Örnek |
|---|---|---|
| Kullanıcı Arayüzü | Talepleri toplar | Web / iOS / Android |
| BFF Katmanı | Aynalar gibi değil, filtre gibi davranır | /mobile/product/123 |
| Çekirdek Servisler | Asıl iş mantığını taşır | Ürün servisi, stok servisi, fiyat servisi |
E tabi burada kritik nokta şu — BFF iş kuralını tamamen üzerine almamalı. Eğer her karar oraya taşınırsa bu sefer orta katman mini-monolite dönüşür. Ben bunu 2024 başında uzaktan takip ettiğim bir fintech projesinde gördüm; ilk ayda harika görünüyordu, üçüncü ayda takım “bu katman niye kendi başına ürün oldu?” diye sormaya başladı. Tam olarak o an. İlk Satırdan Fazlası: Küçük Bir Selamın Büyük Hikâyesi yazımızda bu konuya da değinmiştik.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
BFF iyi kurulduğunda frontend ekibine nefes aldırır; kötü kurulduğunda ise sadece yeni bir darboğaz yaratır.
Nerede işe yarıyor?
Bence en doğal kullanım alanı çok kanallı ürünler. Web sitesi var, mobil uygulama var, belki tablet için ayrı akış var… Hepsinin veri ihtiyacı farklıysa tek endpoint ile ilerlemek açıkçası biraz zorluyor insanı. rehberi ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
E-ticaret örneği hiç fena değil
Düşünün ki aynı ürün kartını web’de detaylı göstermek istiyorsunuz; yorumlar görünsün, benzer ürünler çıksın, teslimat tahmini gelsin. Ama mobilde kullanıcı hızlıca satın almak istiyor ve üç ekran aşağı inmek istemiyor — haklı da. İşte Web BFF uzun cevabı hazırlar, Mobile BFF kısa keser. Orada biter.
Sosyal uygulamalar da aynı dertten muzdarip
Sosyal akışlarda durum daha da karışık olabiliyor. Beğeni sayısı mı gösterilecek, yorum özeti mi gelecek yoksa medya öncelikli mi olacak? Bir arkadaşım Berlin’de çalışan bir ekipte tam bunu yaşadı; tek feed API’si yüzünden Android tarafında gereksiz fotoğraf meta verileri doluşmuştu ve ağ kullanımı ciddi yükselmişti. Gereksiz yere.
Kurum içi panellerde de faydası büyük oluyor,. Yöneticinin görmek istediği şeyle saha çalışanının gördüğü şey aynı olmuyor. Aynı kaynağı paylaşırken ekran bazlı uyarlama yapmak hem düzen getiriyor hem de kod tekrarını azaltıyor.
- Daha temiz istemci deneyimi: Uygulama yalnızca ihtiyacı olan veriyi alır.
- Daha az ağ yükü: Gereksiz alanlar taşınmaz. — ciddi fark yaratıyor
- Daha esnek geliştirme: Her platform kendi hızında ilerleyebilir. (bu kritik)
Peki eksileri yok mu?
Not: BFF sihirli değnek değil; bazı projelerde çözümden çok ek operasyon yükü getirebilir.
Tabii ki var…
Bunu süsleyip püsleyip anlatmaya gerek yok. Yeni servis demek yeni deployment demek, yeni loglama demek, yeni izleme demek. Küçük ekiplerde bu ekstra yük bazen can sıkıyor gerçekten. Hele bir de trafik düşükse ve platform sayısı azsa, BFF kurmanın maliyeti faydasını rahatça geçebilir. TypeScript Utility Type’ları: SaaS’ta Gerçekten İşe Yarayanlar yazımızda bu konuya da değinmiştik.
Açık konuşayım — ben bazı startuplarda sırf mimari “modern görünsün” diye yapılan fazla ayrıştırmalara şahit oldum. Sonra ekip haftanın yarısını gateway, proxy, adapter derken geçiriyor. Güzel fikir, ama henüz ham. Biraz daha pişmesi lazım bazı ekiplerin.
Kod tekrarı meselesi nasıl çözülür?
app.get('/mobile/api/product/:id', async (req,res) => {
const id = req.params.id;
const [product,inventory,maxPrice] = await Promise.all([
productService.getProduct(id),
inventoryService.getInventory(id),
pricingService.getPrice(id)
]);
res.json({
id,
name : product.name,
image : product.mainImage,
price : maxPrice.currentPrice,
stock : inventory.quantity
});
});Coding örneğinde bile küçük sürprizler oluyor ya — işte gerçek hayatta da öyle. Ortak fonksiyonlar düzgün paketlenmezse kopyala-yapıştır kaçınılmaz hale geliyor (ki bu çoğu kişinin gözünden kaçıyor). O yüzden iyi pratik genelde ortak yardımcı kütüphane çıkarmak ya da domain bazlı paylaşılan modüller kullanmak oluyor. Başka çaresi yok.
Küçük startup mı enterprise mı?
Küçük startup’ta önce yalınlık önemli. Tek repo, tek deploy hattı, az insan gücü. Bu ortamda doğrudan backend’i sade tutup frontend ihtiyaçlarını sınırlamak çoğu zaman yeterli oluyor zaten. İki tane tüketiciniz varsa ve işler sakin gidiyorsa ekstra BFF şart olmayabilir — gerçekten olmayabilir. Freelance Pazarındaki Kargaşa Bitiyor mu?: Assignly Ne Vadediyor yazımızda da bu konuya değinmiştik.
Büyük kurumlarda ise tablo değişiyor. Orada güvenlik politikaları, versiyonlama baskısı, birbiriyle yarışan ekipler derken merkezi API’nin omuzlarına fazla yük binebiliyor. Enterprise seviyede benzer yapıları incelerken hep aynı şeyi görüyorum: biri raporlama için geniş payload ister, diğeri performans için minicik cevap ister. Ortası bulunmayınca çatlak büyüyor. Kaçınılmaz.
Kimin ne zaman ihtiyacı olur?
| Senaryo | BFF Mantıklı mi? | Neden |
|---|---|---|
| Küçük MVP | Zayıf ihtimal | Ekip küçükse operasyon yükü artabilir |
| Çok kanallı ürün | Evet | Her kanalın veri ihtiyacı farklıdır |
Az önce startup dedim. Aslında hibrit modeller de epey yaygın; mesela ana backend sabit kalırken sadece mobil için ince bir BFF katmanı açılıyor. Neyse, çok dağıttım — konumuza dönelim.
Bana göre en sağlıklı kullanım şekli ne?
Lafı gevelemeden söyleyeyim: BFF sanıldığı kadar geniş geniş bir model değil. Onu API Gateway ile karıştırmamak gerekiyor (bizzat test ettim). Gateway trafiği yönlendirir; BFF ise deneyimi şekillendirir. Aradaki fark ince görünür ama etkisi büyük — inanın.
Vallahi, Auth, aggregation ve presentation logic’in hepsini tek yere koymaya çalışan ekipler gördüm; sonuç pek hoş olmuyor. En iyi yaklaşım genelde şudur: çekirdek iş mantığı service layer’da kalır, BFF sadece sunum odaklı uyarlamalar yapar, ortak güvenlik kuralları ise merkezi policy ile yönetilir. Bu üçü yerli yerinde olunca sistem hem okunaklı hem de bakımı kolay bir hal alıyor.
Sıkça Sorulan Sorular
BFFF ile API Gateway aynı şey mi？
Nope.API Gateway daha çok trafik kapısıdır,-BFFF front-end’e özel veri şekillendirir.Kısacası biri yol gösterir, diğeri tabağa yemek dizer.
BFFF microservice mimarisinde şart mı？
Zorunlu değil.Ama çoklu kanal varsa ve her kanal farklı data istiyorsa oldukça işe yarar.Tek hedefiniz hızlı MVP ise önce basit başlayıp sonra ihtiyaç oldukça eklemek daha akıllıca olabilir.
Küçük ekiplerde neden dikkat etmek gerekiyor?
Cünkü her yeni katman göz kamaştırıcı olsa da bakım maliyeti getirir. İzleme, hata ayıklama, deployment … hepsi artar. Ekip küçüksa bunun bedeli hissedilir ; özellikle gece yarısı alert yağınca.
İtiraf edeyim, Dilerseniz TypeScript Utility Type’ları: SaaS’ta Gerçekten İşe Yarayanlar yazısına da göz atabilirsiniz; ortak tipleri toparlama konusu burada anlattığımız ayrıştırma fikriyle güzel örtüşüyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
