Backend for Frontend (BFF) deseni: tasarım ve uygulama adımları

BFF deseni hangi sorunu çözer?

Backend for Frontend, her istemci türü için ayrı ve ince bir sunucu katmanı kurma desenidir. Web arayüzü, mobil uygulama ve üçüncü taraf entegrasyonlar aynı genel amaçlı API'ye bağlandığında istekler birbirine karışır: mobil az veri ve az çağrı ister, masaüstü web geniş bir tablo ister, biri için eklenen alan diğerinin yanıtını şişirir. BFF bu çatışmayı, her arayüzün kendi arka kapısını almasıyla çözer.

Deseni yaygınlaştıran Sam Newman, genel amaçlı API'nin zamanla tek bir dağıtım birimine dönüştüğünü ve her ön yüz ekibinin değişiklik için aynı ekibin kapısını çalmak zorunda kaldığını anlatır. Microsoft'un Azure Architecture Center sayfası da aynı gerekçeyi verir: BFF, arayüze özgü gereksinimleri ele alan yeni bir katmandır ve ön yüz ekibine dil seçimi, yayın temposu ve öncelik belirleme konusunda özerklik tanır.

BFF iş kurallarının yeri değildir. Fiyat hesabı, stok kuralı ya da yetki politikası alttaki servislerde kalır; BFF yalnızca o istemcinin deneyimine ait olanı yapar: çağrıları birleştirmek, yanıtı ekrana uygun şekle sokmak, oturumu yönetmek.

Ne zaman BFF kurulur, ne zaman gerekmez?

BFF'in karşılığı bir bedeldir: her yeni servis ayrı bir dağıtım, izleme ve güvenlik yüzeyi demektir. Bu yüzden karar ihtiyaca göre verilir.

BFF'e yönelten işaretler: • Mobil ve web aynı uç noktadan farklı alt kümeleri çekiyor ve yanıtlar ortak paydaya göre şişiyor. • Tek bir ekran için istemci birkaç servise art arda gidiyor ve ağ süresi ekranda hissediliyor. • Ön yüz ekibi, genel API ekibinin sırasını beklediği için ekran değişiklikleri yavaşlıyor. • Arayüzler farklı oturum biçimleri gerektiriyor: tarayıcı çerezi bir yanda, mobil cihazda depolanan token diğer yanda.

Gerekmeyen durumlar da vardır. Tek bir arayüzünüz varsa ve API zaten o arayüze göre tasarlandıysa ek katman yalnızca gecikme ve bakım yükü getirir. Microsoft belgesi, istemcilerin kendi ihtiyacını sorguyla seçebildiği GraphQL yaklaşımında ayrı BFF ihtiyacının azalabildiğini de not eder. Kararı verirken ekip yapısına bakın: BFF'i ön yüz ekibi sahipleniyorsa desen çalışır, ayrı bir arka uç ekibine devredilirse eski darboğaz yeni adla geri döner.

Adım adım BFF nasıl tasarlanır?

Sağlıklı bir BFF, kod yazmadan önce sınırın çizilmesiyle başlar. Şu sırayı izleyin: • Ekran envanteri çıkarın. Her ekranın hangi verilere ihtiyaç duyduğunu ve bugün kaç servise gittiğini yazın. • İstemci başına bir BFF sınırı belirleyin. Web ve mobil için ayrı sunucu katmanı en açık ayrımdır; birbirine çok benzeyen arayüzleri ortak BFF'te tutmak mümkündür ama gereksinimler ayrıştıkça bölmek gerekir. • Uç noktaları ekran odaklı adlandırın. Genel kaynak adları yerine, örneğin sipariş özeti ya da ana sayfa akışı gibi ekranın ihtiyacını karşılayan uçlar tasarlayın. • Alt servis çağrılarını BFF'te birleştirin. Birbirine bağımlı olmayan çağrıları paralel yürütün, birbirine bağlı olanları sıraya koyun. • Yanıtı ekrana göre kırpın ve adlandırın. Alt servisin iç alan adlarını istemciye sızdırmayın. • Hata ve zaman aşımı davranışını ekran bazında belirleyin: hangi parça gelmezse ekran yine de açılabilir, hangisi zorunludur? • Ortak kaygıları katmana taşımayın. İzleme, kimlik doğrulama ve hız sınırı gibi kesişen işler ortak altyapıda (örneğin ağ geçidi) kalmalı; BFF'e kopyalanırsa her istemci katmanında yeniden yazılır.

Örnek: mobil sipariş özeti ucu

Örneğin bir perakende uygulamasında mobil ekran yalnızca sipariş durumunu ve kalem adlarını göstersin; web ekranı ise fatura ve adres ayrıntısını da istesin. Mobil BFF'te ilgili uç şuna benzer (Node.js ile kurgusal bir taslak):

app.get('/mobile/order-summary', async (req, res) => { const customer = req.session.customerId; const [order, shipping] = await Promise.all([ orderService.latestOrder(customer), shippingService.status(customer) ]); res.json({ status: shipping.status, items: order.items.map(i => ({ name: i.name, qty: i.qty })) }); });

Burada şunlar gerçekleşir: alt çağrılar paralel çalışır, yanıt yalnızca ekranın kullandığı alanlara indirilir ve istemci iç servis adlarını hiç görmez. Web BFF'i aynı servisleri çağırıp fatura ve adres alanlarını da ekleyebilir. Alt servislerden biri yavaşlarsa karar BFF'te verilir: kargo bilgisi gelmezse ekran yine de sipariş kalemleriyle açılır ve status alanı belirsiz gösterilir. Bu esneklik, genel amaçlı API'de tek bir yanıt şemasına sığdırılamaz.

Oturum, güvenlik ve işletim

BFF, tarayıcı tabanlı uygulamalarda güvenlik açısından da değerlidir. Erişim ve yenileme token'larını tarayıcı JavaScript'inde tutmak yerine BFF'te saklayıp tarayıcıya yalnızca HttpOnly çerez vermek, token'ın betik tarafından okunma riskini azaltır. Tarayıcı BFF'e çerezle gelir; BFF alt servislere token ile gider. Çerez tabanlı akışta istekler arası sahteciliğe karşı koruma (CSRF önlemi) tasarımın parçası olmalıdır.

İşletim tarafında şunlara dikkat edin: • Her BFF'in ayrı sağlık denetimi, günlük kaydı ve gecikme ölçümü olsun; ekran bazında hata oranı görmek BFF'in en büyük kazanımlarındandır. • Zaman aşımı değerlerini alt servis bazında tanımlayın ve devre kesici (circuit breaker) uygulayın; yavaş bir servis tüm ekranı kilitlemesin. • Önbelleği yalnızca kullanıcıdan bağımsız veriler için kullanın; kişiye özel yanıtlar paylaşılan önbelleğe girerse veri sızıntısı olur. • Sürümlemeyi istemciyle birlikte yönetin: BFF ve ön yüz aynı ekibin olduğu için birlikte yayın yapmak mümkündür, bu özerklik desenin ana faydasıdır.

BFF'te sık yapılan hatalar

En sık hata, BFF'i yeni bir genel amaçlı arka uca çevirmektir. İş kuralı, veri doğrulama ya da yetki politikası BFF'e girerse aynı kural web ve mobil BFF'te ayrı ayrı yazılır ve zamanla birbirinden ayrılır. Kural alt serviste kalmalı, BFF yalnızca çağırmalıdır.

Bir başka hata, BFF'i her istemci ve her ekran için büyütmektir. Katman şişince bir mini monolit oluşur. Uç noktaları ekran sınırlarında tutun, ortak parçaları paylaşılan kütüphaneye çıkarın ama kütüphaneyi iş mantığıyla doldurmayın.

Bir diğer hata, ek ağ sıçramasının gecikmesini ölçmemektir. BFF çağrıyı kısaltması gerekirken uzatıyorsa, paralel çağrı ve ekran bazlı önbellekle telafi edin. Sahiplik belirsizliği de sık görülür: BFF'i kimin yayınladığı, kimin nöbet tuttuğu baştan netleşmezse katman sahipsiz kalır. Son olarak kod tekrarı kaçınılmaz bir bedeldir; bunu bilinçli kabul edip yalnızca gerçekten ortak olan teknik parçaları ortaklaştırın.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

BFF kararı çoğu zaman yazılım mimarları, ön yüz ve arka uç ekip liderleri ile platform mühendislerinin ortak masasında verilir. Mindset kataloğundaki Backend for Frontend (BFF) Deseni eğitiminin modül başlıkları bu akışı izler: BFF deseni ve sınır tasarımı, API kompozisyonu ve veri şekillendirme, güvenlik, oturum ve operasyon. Yani sınırın nereye çizileceği sorusundan, yanıtın nasıl birleştirileceğine ve canlıda nasıl işletileceğine uzanan tam bir çerçeve sunar.

Kurumsal ekipler için en doğrudan karşılığı, web ve mobil ekiplerin aynı arka uca bağımlı olduğu ve yayın temposunun yavaşladığı yapılardır. Eğitim bu ekiplerin ortak bir sınır dilini oluşturmasına yardım eder. Mimari ölçeği daha geniş bir bakış arayanlar için mikroservis ve API tasarımı alanındaki diğer programlar tamamlayıcıdır.