React + Spring Full-Stack Mimari: BFF Deseni Rehberi
React ön yüz ile Spring backend arasında BFF (Backend for Frontend) deseni: ne zaman gerekir, kimlik ve oturum yönetimi, agregasyon, sözleşme disiplini ve alternatiflerle karşılaştırma.
BFF nedir ve hangi problemi çözer?
BFF (Backend for Frontend), belirli bir ön yüzün — web, mobil, ortak paydaşı olmayan her istemcinin — ihtiyaçlarına göre şekillenmiş, o ön yüze adanmış ince bir backend katmanıdır. Çözdüğü problem nettir: genel amaçlı API'ler hiçbir istemciye tam uymaz; istemciler ya fazla veri çeker ya çok istek atar ya da iş mantığını kendine kopyalar. BFF, bu uyumsuzluğu istemciye en yakın sunucu katmanında çözer.
Ne zaman BFF, ne zaman doğrudan API?
Durum | Doğrudan API yeterli | BFF sinyali |
|---|---|---|
İstemci sayısı | Tek web istemcisi | Web + mobil + üçüncü taraf, farklı ihtiyaçlarla |
Sayfa başına çağrı | 1-2 uç nokta | Bir ekran 5+ servisten veri topluyor |
Kimlik modeli | Basit token akışı yeterli | Tarayıcıda httpOnly oturum + token saklama sunucuda isteniyor |
Yanıt biçimlendirme | Backend DTO'ları ekrana uyuyor | Ekran modeli backend modelinden belirgin farklı |
Ekip yapısı | Tek full-stack ekip | Frontend ekibi kendi sunucu katmanını yönetebiliyor |
BFF'nin üç ana görevi
Agregasyon: bir ekranın ihtiyacı olan veriyi birden çok Spring servisinden toplayıp tek yanıtta, ekran modeli olarak döndürmek — istemcide çağrı orkestrasyonu ve şelale (waterfall) gecikmesi biter. Uyarlama: alan adlarının, biçimlerin ve sayfalama modelinin ekrana göre düzenlenmesi; backend sözleşmesi değişse bile ekran sözleşmesinin korunması. Kimlik sınırı: tarayıcıya token sızdırmadan oturum yönetimi — aşağıda ayrıca ele alıyoruz. Bu üç görevin ortak kuralı: BFF'ye iş kuralı yazılmaz; iş kuralı alan servislerinde kalır, BFF yalnızca deneyim katmanıdır. Bu çizgi bulanıklaştığında BFF, bakımı zor ikinci bir monolite dönüşür.
Kimlik ve oturum: BFF'nin en güçlü gerekçesi
SPA'larda token saklama ikilemini (localStorage'ın XSS riski) kökten çözen model, token'ların tarayıcıya hiç inmemesidir: OAuth/OIDC akışını BFF yürütür; access/refresh token'lar sunucu tarafında tutulur; tarayıcı ile BFF arasında yalnızca httpOnly + Secure + SameSite oturum çerezi çalışır. React istemcisi hiçbir token görmez; BFF, arka servis çağrılarına token'ı kendisi ekler. Bu desen, güvenlik denetimlerinde 'token nerede saklanıyor?' sorusunun en temiz cevabıdır — ve CSRF korumasının (SameSite + token) BFF'de doğru kurulmasını şart koşar.
Spring tarafında uygulama
BFF, Spring ekosisteminde iki olgun yolla kurulur: yüksek eşzamanlı agregasyon için WebFlux/WebClient tabanlı reaktif bir servis veya Java 21 sanal thread'leriyle sade blocking model — ikisi de paralel arka uç çağrılarını verimli yönetir. Spring Cloud Gateway, yönlendirme + filtre ihtiyaçları BFF'ye yaklaştığında hazır bir iskelet sunar; OAuth istemci desteği (spring-security-oauth2-client) yukarıdaki oturum desenini standart bileşenlerle kurar. Dayanıklılık asgarisi: her arka uç çağrısında zaman aşımı, kısmi hata stratejisi (ekranın tamamını düşürmek yerine bölüm bazlı hata) ve devre kesici.
Sözleşme disiplini: ekran modeli de bir API'dir
BFF'nin döndürdüğü ekran modelleri, frontend ile BFF arasındaki resmî sözleşmedir: OpenAPI ile tanımlanmalı, TypeScript tipleri bu tanımdan üretilmeli ve kırıcı değişiklikler sürümlenmelidir. GraphQL, aynı problemin alternatif çözümüdür — esnek sorgu gücüne karşılık sunucu tarafında karmaşıklık (N+1 çözümleyiciler, sorgu maliyet kontrolü) getirir; ekip GraphQL olgunluğuna sahip değilse, iyi tasarlanmış REST tabanlı BFF çoğu kurumsal senaryoda daha öngörülebilirdir.
İş etkisi: ekip hızının mimari karşılığı
BFF'nin getirisi ekran geliştirme hızında ölçülür: frontend ekibi, backend sprint'ini beklemeden kendi katmanında alan ekleyip biçim değiştirir; mobil ve web, birbirinin API'sini bozmadan evrilir. Maliyeti de dürüstçe yazılmalıdır: işletilecek bir servis daha, bir dağıtım hattı daha. Karar kriterimiz pratiktir: ekran başına çağrı sayısı, token saklama gereksinimi ve istemci çeşitliliği tabloda BFF'yi işaret ediyorsa yatırım kendini hızla öder; etmiyorsa doğrudan API + iyi DTO tasarımı yeterlidir.
Sık sorulan sorular
BFF, API Gateway ile aynı şey mi?
Hayır: gateway istemciden bağımsız, yatay bir altyapı katmanıdır (yönlendirme, hız limiti, TLS); BFF belirli bir ön yüze adanmış deneyim katmanıdır. Birlikte kullanılabilirler.
Her istemci için ayrı BFF şart mı?
Desenin adı bunu önerir ama pragmatizm esastır: ihtiyaçları gerçekten ayrışan istemciler ayrı BFF'yi hak eder; benzer iki web deneyimi tek BFF'yi paylaşabilir.
Next.js API route'ları BFF sayılır mı?
İşlevsel olarak evet — aynı görevleri üstlenebilir. Kurumsal Java ekosisteminde Spring tabanlı BFF; ekip yetkinliği, gözlemlenebilirlik ve güvenlik standartlarıyla bütünleşme açısından çoğu zaman daha uyumludur.
BFF iş mantığı kayması nasıl önlenir?
Yazılı kuralla ve kod incelemesiyle: BFF'de veri birleştirme ve biçimlendirme serbest, iş kuralı ve kalıcı durum yasak. Kuralın testi şudur: aynı kural ikinci bir istemcide de gerekiyorsa yeri alan servisidir.
BFF kontrol listesi
BFF ihtiyacı karar tablosuyla doğrulandı
Token'lar sunucuda; tarayıcıda yalnızca httpOnly oturum çerezi
CSRF koruması (SameSite + token) BFF'de kurulu
Arka uç çağrılarında zaman aşımı + devre kesici + kısmi hata stratejisi
Ekran modelleri OpenAPI ile tanımlı; TS tipleri üretiliyor
İş kuralı sınırı yazılı; kod incelemesinde denetleniyor
BFF metrikleri (ekran başına gecikme, arka uç kırılımı) panoda
SSH Yazılım, React + Spring projelerinde BFF mimarisi tasarımı ve uygulamasını uçtan uca gerçekleştirir. Ön yüz-backend sınırınızı birlikte netleştirelim.