Skip to main content

> backend-for-frontend_(bff)_mimari_kalıbı

Backend-for-Frontend (BFF) Mimari Kalıbı

Backend-for-Frontend (BFF) kalıbı, 'herkese uyan tek genel API' hantallığını önleyerek mobil, web ve IoT istemcilerine özel veri boyutları ve güvenlik sınırlarını nasıl oluşturur?

Stack: SOFTWARE ARCHITECTURE STACK →Senior (L5-L6)pattern

ÖZET VE TEKNİK CEVAP

Doğrudan ön yüz ekipleri tarafından yönetilen, alt mikroservis çağrılarını birleştiren, gereksiz veri alanlarını budayan, ikili protokolleri çeviren ve istemciye özel oturum çerezlerini yöneten istemciye özel ağ geçitleri kurarak.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

iOS, Android, Web ve Üçüncü Taraf entegrasyonlarını tek bir genel REST API'yi tüketmeye zorlamak yerine (bu durum mobilde yüzlerce gereksiz masaüstü alanının indirilmesine veya tek ekran için 8 ardışık HTTP çağrısına yol açar), BFF kalıbı her istemci türüne özel hafif bir arka plan servisi atar. Mobil BFF, dahili mikroservislere eşzamanlı gRPC çağrıları atar, yanıtı telefon ekranının ihtiyaç duyduğu 5 alana budar, görselleri retina çözünürlüğüne göre biçimlendirir ve istemciye 50 ms altında tek bir JSON döner.

2. Doğru Kullanım Senaryosu

Arka planda çok sayıda ince taneli mikroservisin çalıştığı ve farklı istemcilerin (Mobil, Web SPA, Akıllı TV, Sesli Asistan) bulunduğu çok platformlu sistemler.

3. Prodüksiyon Arıza Modları

1) İş Mantığı Sızıntısı: BFF'i saf bir sunum birleştiricisi olarak tutmak yerine içine veritabanı sorguları veya çekirdek iş kuralları yazmak; 2) Kod Kopyalama Kayması: 4 ayrı BFF projesinde kimlik doğrulama veya hız sınırlama mantığını baştan yazıp zamanla ayrıştırmak; 3) Kontrolsüz İç Servis Patlaması: Tek bir mobil BFF ucunun aynı anda 25 iç mikroservisi çağırarak bağlantı havuzlarını kilitlemesi.

4. Teşhis ve Telemetri Sinyalleri

Mobil istemcilerin oturum başına harcadığı hücresel veri boyutu, istemci ekranlarındaki ağ şelale (waterfall) çağrı sayısı, BFF alt servis eşzamanlılık metrikleri ve ön yüz-arka yüz ekipleri arasındaki dağıtım sürtünmesi.

5. Önleme ve Mimari Bariyerler

'BFF İçinde İş Mantığı Yasaktır' kuralını katı şekilde uygulayın (BFF yalnızca çeviri ve birleştirme katmanıdır); ortak güvenlik ara katmanlarını paylaşılan kütüphanelerle yönetin ve alt servislere giden çağrılarda katı zaman aşımı ve devre kesiciler (circuit breakers) kullanın.

6. Mimari Ödünleşimler (Trade-offs)

Ön yüz kullanıcı deneyimini, mobil pil ömrünü ve ekiplerin bağımsız dağıtım hızını zirveye taşır; buna karşılık birden fazla arka plan servisi yönetme ve bakım operasyonel maliyeti getirir.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO Vaka İncelemesi: Bir mobil alışveriş uygulaması ana ekranı çizmek için 9 ayrı HTTP çağrısı yapıyordu (Profil, Öneriler, Sepet, Kampanyalar, Bannerlar) ve 4G ağında açılış 3.8 saniye sürüyordu. Mobil BFF kurularak bu 9 çağrı düşük gecikmeli iç gRPC üzerinden birleştirildi ve istemciye 110 ms'de 4KB'lık sıkıştırılmış tek bir JSON teslim edildi.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

Backend-for-Frontend (BFF) servisinin sahibi ve bakımından sorumlu ekip kim olmalıdır?

İlgili istemci uygulamasını geliştiren ön yüz ekibi (örn. iOS ekibi iOS BFF'in sahibidir); bu sayede arka yüz ekiplerini beklemeden API sözleşmelerini bağımsızca evriltebilirler.
Q2

Bir BFF mobil ağlarda 'Fazla Veri Çekme' (Over-Fetching) sorununu nasıl önler?

Dahili mikroservisler 80 alanlık zengin iş modelleri dönerken, BFF kullanılmayan tüm alanları budar ve telefondaki o ekranın ihtiyaç duyduğu yalnızca 4-5 alanı gönderir.
Q3

Bir BFF içinde asla aşılmaması gereken mimari sınır nedir?

Bir BFF asla ana veritabanı veya temel iş kurallarını barındıran bir merkeze dönüşmemelidir; kesinlikle sadece bir sunum biçimlendirme ve birleştirme adaptörüdür.

Backend-for-Frontend (BFF) Mimari Kalıbı — Sıkça Sorulan Sorular

BFF kalıbı birleşik bir GraphQL Ağ Geçidi ile nasıl karşılaştırılır?

GraphQL istemcilerin tek bir şemadan dinamik alan seçmesini sağlarken, BFF farklı ekiplerin yönettiği optimize edilmiş özel uçlar sunar. Birçok ekip BFF mimarisini GraphQL teknolojisiyle inşa eder.

Masaüstü Web ile Mobil Web aynı BFF'i paylaşmalı mıdır?

Genellikle evet, çünkü aynı web kod tabanından (responsive React/Next.js) beslenirler. Ayrı BFF'ler, yerel mobil uygulamaların (iOS/Android) radikal farklı yaşam döngüsü ve veri kısıtları olduğunda anlam kazanır.

Bir BFF kullanıcı kimlik doğrulamasını nasıl yönetir?

Web BFF'leri tarayıcıları XSS token hırsızlığından korumak için güvenli HttpOnly SameSite çerezlerini yönetir ve bu çerezleri iç mikroservisler için Bearer JWT belirteçlerine çevirir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Sam Newman, 2015 yılında SoundCloud'un mobil modernizasyonu sırasında Backend-for-Frontend (BFF) kalıbını popülerleştirmiştir.
  • ▸BFF, ön yüz ekiplerinin merkezi platform ekiplerine bağımlı kalmadan aynı geliştirme döngüsünde (sprint) API değişikliklerini canlıya almasını sağlar.

Yaygın Yanılgılar

  • ✗Her sayfanın kendi BFF'ine ihtiyacı olduğunu sanmak; BFF sayfa başına değil, istemci türü (iOS, Android, Web SPA) başına tanımlanır.

Karar Kılavuzu & Önceliklendirme

Mobil uygulamalarınız çoklu ardışık API çağrıları yüzünden yüksek gecikme yaşadığında veya ön yüz ekipleriniz merkezi backend dağıtım takvimlerine takıldığında BFF kalıbını uygulayın.

Doğrulanmış Kaynaklar & Referanslar