Backend for Frontend (BFF) Deseni 2026: Çoklu İstemci için API Katmanı

Backend for Frontend (BFF) Deseni Nedir ve Neden Gerekir?

Backend for Frontend (BFF), her istemci tipine (web, mobil, akıllı TV, masaüstü) özel bir API katmanı koymanın desenidir: tek bir genel amaçlı API’yi tüm istemcilere zorlamak yerine, her arayüzün kendi ihtiyacına biçilmiş ince bir backend’i olur. Bu katman, alt servislerden gelen veriyi birleştirir, istemcinin tam ihtiyacı kadarını döndürür ve ağır işlemi sunucu tarafına alır. Sonuç: mobilde aşırı veri çekme (over-fetching) ortadan kalkar, payload küçülür, batarya ve veri tüketimi düşer.

SoundCloud ve Netflix gibi ekiplerin popülerleştirdiği BFF, 2026’da mikroservis ve mobil-öncelikli mimarilerin standart bir bileşenidir. Tek bir API’nin hem 4K akıllı TV hem 3G mobil cihaza hizmet etmeye çalışması, her zaman ya birini ya diğerini cezalandırır; BFF bu gerilimi mimari düzeyde çözer. Bir akıllı TV uygulaması zengin, büyük payload ile rahatça çalışırken aynı yanıtı düşük bant genişliğindeki bir mobil cihaza göndermek hem yükleme süresini uzatır hem kullanıcının veri paketini eritir. Tersine, mobil için optimize edilmiş yalın bir yanıt da TV deneyimini fakirleştirir. Bu uzlaşmazlık, tek API modelinin yapısal sınırıdır ve istemci sayısı arttıkça keskinleşir. Aşağıdaki bölümler deseni, varyantlarını ve üretim tuzaklarını sayısal olarak açar.

Genel API ile BFF Arasındaki Fark

Genel amaçlı tek API, tüm istemcileri ortak bir sözleşmeyle besler; bu da her istemcinin ortalama bir uzlaşmaya razı olması demektir. Mobil, ihtiyacı olmayan alanları da indirip atar; web, birden çok endpoint’i sırayla çağırarak gecikme biriktirir. BFF ise sorumluluğu istemci ekibine yakınlaştırır: her arayüz, kendi backend’ini kendi temposunda evrimleştirir.

BFF, API Gateway ile karıştırılmamalıdır. Gateway çapraz kesen ilgileri (kimlik doğrulama, rate limit, routing) merkezi yönetir; BFF ise istemciye özgü veri biçimlendirme ve toplama (aggregation) yapar. İkisi birlikte kullanılır: API Gateway güvenlik katmanı trafiği karşılar, arkasındaki BFF istemciye göre şekillendirir.

Bu ayrımın pratik sonucu, sorumlulukların net biçimde katmanlanmasıdır. Conway yasasının ortaya koyduğu üzere, bir sistemin mimarisi onu üreten organizasyonun iletişim yapısını yansıtır; tek genel API modeli, tüm istemci ekiplerini tek bir backend ekibinin temposuna bağlayarak bu yasayı tersine çevirmeye çalışır ve kaçınılmaz olarak bir darboğaz yaratır. BFF deseni ise mimariyi organizasyona hizalar: web ekibi kendi BFF’ini, mobil ekibi kendi BFF’ini sahiplenir ve bağımsız evrimleştirir. Bu sahiplik hizalaması, ölçülebilir bir dağıtım hızı kazancına dönüşür; istemci ekipleri birbirini beklemeden üretime çıkar. Genel amaçlı API’nin bir diğer gizli maliyeti, her istemcinin “ortalama” bir sözleşmeye razı olmasıdır: ne 4K TV için zengin ne 3G mobil için yalın olan bu sözleşme, her iki uçta da suboptimaldir. BFF bu uzlaşmayı ortadan kaldırarak her istemciye tam ihtiyacı kadarını sunar.

BFF Varyantları: İstemci-Başına, Deneyim-Başına ve GraphQL

BFF tek bir şekle sahip değildir; üç yaygın varyant farklı ölçeklerde işe yarar. Seçim, istemci sayınıza ve ekip yapınıza bağlıdır. Yanlış varyant, ya gereksiz bakım yüküne ya da yetersiz özelleştirmeye yol açar; bu yüzden kararı baştan bilinçli vermek gerekir.

1. İstemci-başına BFF: Her platform (iOS, Android, Web) için ayrı backend. En yüksek özelleştirme, en yüksek bakım yükü.
2. Deneyim-başına BFF: Benzer cihazlar tek BFF’te gruplanır (örneğin tüm mobil tek BFF). Bakım ile özelleştirme dengesi.
3. GraphQL tabanlı BFF: Tek bir GraphQL şeması, her istemcinin kendi sorgusuyla tam ihtiyacını çekmesini sağlar. BFF mantığının büyük kısmını istemciye taşır.

BFF Mimarisinin Çalışma Akışı

Tipik bir BFF isteği şu zinciri izler: istemci → API Gateway → ilgili BFF → çoklu alt servis → BFF’te birleştirme → istemciye biçimlenmiş yanıt. BFF, alt servislere paralel çağrı yapar (fan-out), gelen veriyi tek bir istemci modeline indirger (fan-in) ve gereksiz alanları kırpar. Bu fan-out/fan-in akışı, istemcinin tek bir round-trip ile ihtiyacı olan her şeyi almasını sağlar; aksi halde istemci kendisi dört ayrı endpoint’i sırayla çağırıp sonuçları kendi tarafında birleştirmek zorunda kalır ki bu hem gecikme biriktirir hem de batarya ve veri tüketir. BFF, bu birleştirme yükünü istemciden alıp veri kaynağına yakın, hızlı bir sunucu katmanına taşır.

• Toplama (aggregation): Bir ekran 4 servisten veri istiyorsa, BFF bu 4 çağrıyı paralel yürütür ve tek yanıtta birleştirir.
• Dönüştürme (transformation): Alt servis tarih formatı ISO döndürürken mobil istemci farklı format istiyorsa, dönüşüm BFF’te yapılır.
• Daraltma (trimming): İstemcinin kullanmadığı alanlar yanıttan çıkarılır.
• Önbellekleme: İstemciye özel TTL ile BFF katmanında önbellek tutulur.

Mobil için BFF kurarken mobil ve web BFF deseni ile doğru protokol seçimi birlikte değerlendirilmelidir. gRPC, BFF ile alt servisler arası iç iletişimde düşük gecikme sağlar; istemci tarafında REST veya GraphQL tercih edilir.

Fan-out/fan-in akışının doğru uygulanması, BFF’in en büyük performans kazancının kaynağıdır. Naif bir BFF, dört alt servisi sırayla çağırırsa toplam gecikme dört çağrının toplamı olur; paralel çağırırsa toplam gecikme yalnızca en yavaş çağrı kadardır. Bu fark, dört servisin her biri 100 ms sürdüğünde 400 ms ile 100 ms arasındaki ayrımdır; yani sıralı yerine paralel fan-out, bu örnekte gecikmeyi dörtte birine indirir. Bu nedenle BFF kodu, bağımsız çağrıları her zaman eşzamanlı başlatmalıdır (Promise.all, eşzamanlı goroutine veya reaktif birleştirme). Yalnızca bir çağrının çıktısı diğerine girdi olduğunda sıralı yapılması zorunludur; bu durumda bile bağımlı olmayan çağrılar paralelden ayrılmalıdır. Daraltma (trimming) ise bant genişliği tarafında kazanç sağlar: alt servis 40 alan döndürse de istemci yalnızca 8’ini kullanıyorsa, BFF kalan 32 alanı yanıttan çıkararak payload’u ve serileştirme maliyetini düşürür.

Performans Etkisi: Sayılarla Karşılaştırma

BFF’in ölçülebilir kazancı en çok mobil ve düşük bant genişliğinde görülür. Aşağıdaki tablo, tipik bir e-ticaret ana ekranı için tahmini iyileşmeleri özetler. Değerler ölçüm bağlamına göre değişir, ancak yön tutarlıdır.

BFF Anti-Desenleri ve Kaçınılması Gerekenler

BFF yanlış uygulandığında çözüm değil, ek bir bakım borcu olur. En kritik anti-desen, BFF’e iş mantığı kaymasıdır: BFF yalnızca toplama, dönüştürme ve biçimlendirme yapmalı, alan iş kuralları alt servislerde kalmalıdır.

• Şişman BFF: İş mantığı BFF’e sızar, alt servisler anemik kalır. Çözüm: kuralları domain servisine geri taşı.
• BFF patlaması: Her küçük istemci varyantı için yeni BFF açılır, kod tekrarı katlanır. Çözüm: deneyim-başına gruplama veya GraphQL’e geç.
• Paylaşılan BFF: İki istemci tek BFF’i zorlar, genel API’nin sorununu geri getirir. Çözüm: gerçek ihtiyaç ayrışıyorsa böl.

Dayanıklılık Desenleri: BFF’i Çökmez Kılmak

BFF, alt servislere fan-out yapan bir toplama katmanı olduğu için tek bir alt servisin yavaşlaması ya da çökmesi tüm ekranı düşürebilir. Bu yüzden BFF dayanıklılık desenleri olmadan üretime alınmaz. Devre kesici (circuit breaker), zaman aşımı, yeniden deneme ve kısmi yanıt (graceful degradation) bu katmanın hayati bileşenleridir. Sam Newman’ın BFF mimari deseni notları ve Martin Fowler’ın Circuit Breaker yazısı bu desenleri ayrıntılı açıklar.

Bu desenler BFF’i kırılgan bir aracı katman olmaktan çıkarıp sistemin dayanıklılık çıpasına dönüştürür. Özellikle mobil istemcilerde, ağ koşulları değişken olduğu için kısmi yanıt ve agresif önbellekleme kullanıcı algısını doğrudan iyileştirir.

Dayanıklılık desenlerinin neden bu kadar kritik olduğunu bir hesap netleştirir. Bir BFF, tek bir ekran için dört alt servise paralel fan-out yapıyorsa ve her servisin tek tek erişilebilirliği %99,9 ise, dört servisin aynı anda başarılı olma olasılığı yaklaşık %99,9 üzeri 4, yani %99,6’ya düşer; sekiz servisle bu oran %99,2’ye iner. Yani BFF, bağımlılık sayısı arttıkça matematiksel olarak en zayıf halkadan daha kırılgan hale gelir. Devre kesici ve kısmi yanıt bu denklemi tersine çevirir: kritik olmayan bir servis çöktüğünde BFF, o bölümü boş veya önbellekten doldurarak ekranın geri kalanını sunar; böylece tek bir servis arızası tüm deneyimi düşürmez. Zaman aşımı bütçesi de aynı derecede önemlidir; fan-out çağrılarından biri yanıt vermeden askıda kalırsa, zaman aşımı olmadan tüm yanıt o yavaş servisin hızına kilitlenir. Pratik kural, her alt servis çağrısına ekranın toplam gecikme bütçesinin bir dilimini ayırmak ve bu bütçe aşıldığında o servisi kısmi yanıtla atlatmaktır. Bulkhead deseni ise bir servise giden çağrıların ayrı bir thread/bağlantı havuzunda izole edilmesini sağlar; böylece yavaşlayan bir servis, diğer servislere giden çağrıların kaynaklarını tüketip onları da boğamaz.

BFF Ne Zaman Gerekmez?

BFF her projeye gerekmez ve gereksiz katman ek gecikme ile bakım maliyeti getirir. Tek istemcisi olan erken aşama bir üründe, basit bir REST API yeterlidir. BFF, çoklu istemci, belirgin platform farklılıkları ve istemci ekiplerinin bağımsız dağıtım ihtiyacı doğduğunda anlam kazanır.

• Tek istemci (sadece web) → BFF gerekmez, genel API yeterli.
• İstemciler arası fark minimal → tek API + alan seçimi (sparse fieldsets) yeterli.
• Ekip küçük, bakım kapasitesi sınırlı → GraphQL BFF tek katman olarak tercih edilir.

Tipik Sorunlar ve Çözümleri

BFF üretimde en çok gecikme zinciri, kod tekrarı ve sahiplik belirsizliği nedeniyle sorun çıkarır. Aşağıdaki çözümler sahada doğrulanmıştır:

• Fan-out gecikmesi: BFF alt servisleri sırayla çağırıyor, gecikme topluyor. Çözüm: paralel çağrı (Promise.all / concurrent fetch) ve zaman aşımı bütçesi koy.
• Tek hata tüm ekranı düşürüyor: Bir alt servis çökünce BFF yanıt vermiyor. Çözüm: kısmi yanıt (graceful degradation) ve devre kesici (circuit breaker) ekle.
• Kod tekrarı: Üç BFF aynı dönüşüm mantığını kopyalıyor. Çözüm: ortak kütüphaneye çıkar, ama domain mantığını sızdırma.
• Sahiplik belirsizliği: BFF’i hangi ekip yönetecek belli değil. Çözüm: BFF’i istemci ekibine ver, Conway uyumu sağla.
• Önbellek tutarsızlığı: İstemci eski veri görüyor. Çözüm: BFF düzeyinde TTL ve invalidasyon stratejisi tanımla.
• Güvenlik delikleri: BFF alt servisleri doğrudan açığa çıkarıyor. Çözüm: yetkilendirmeyi BFF’te zorla, alt servisleri ağ içinde izole et.

Sonuç ve Öneriler

BFF deseni, çoklu istemcili sistemlerde tek genel API’nin yarattığı over-fetching, çoklu round-trip ve sürüm kilidi sorunlarını ortadan kaldırır. Doğru uygulandığında mobil payload’unu yarıya indirir, P95 gecikmeyi belirgin düşürür ve istemci ekiplerine bağımsız dağıtım özgürlüğü verir. Başlangıçta deneyim-başına gruplama en dengeli seçimdir; istemci sayısı arttıkça GraphQL tabanlı BFF bakım yükünü azaltır. BFF’i ince tutun, iş mantığını sızdırmayın, paralel fan-out ve devre kesici ile dayanıklılık ekleyin. Tek istemcili erken aşama ürünlerde ise BFF’i ertelemek doğru karardır.

Sıkça Sorulan Sorular