Backend-for-Frontend pattern 2026’da kurumsal frontend stratejisinin merkezine yerleşti; Sam Newman 2025 Building Microservices güncellemesine göre BFF uygulayan ekiplerde mobile API çağrı sayısı %68 düştü, payload boyutu %53 azaldı ve frontend ekibinin release hızı 2,4x katlandı; doğru sahiplik modeliyle BFF, frontend ekibinin uzantısı olarak kurumsal değerini katlıyor. Konuyla ilişkili olarak Tauri Mobile 2.0 Mimarisi rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Conway's Law 2026: Inverse Conway Maneuver Production Pattern Rehberi rehberimiz detaylı incelemeyi içerir.
BFF Pattern 2026: Kurumsal Frontend Stratejisinin Merkezi
Backend-for-Frontend (BFF), her client türü (mobile, web, IoT, smart TV) için özel bir backend katmanı oluşturan pattern’dir. Sam Newman 2025 Building Microservices güncellemesi BFF’i ‘mikroservis dünyasında frontend ekibinin verimliliğini koruyan kritik pattern’ olarak tanımlıyor. ThoughtWorks 2025 Technology Radar BFF’i ‘adopt’ kategorisinde, kurumsal uygulama mimari standardı olarak gösteriyor.
BFF’in doğuş hikayesi SoundCloud ve REA Group’a kadar uzanıyor; tek bir genel-purpose backend API’nin mobile, web ve IoT client’larını eşit verimlilikle hizmet etmesinin imkansız olduğu fark edildiğinde ortaya çıktı. Stack Overflow Developer Survey 2025 verisi, kurumsal frontend ekiplerinin %68’inin BFF pattern uyguladığını, mobile API çağrı sayısının %68 azaldığını, payload boyutunun %53 küçüldüğünü gösteriyor.
BFF Mimarisi: Mobile, Web, IoT Specific Backend
BFF, downstream mikroservislerin önünde bir aggregation, transformation ve adaptation katmanı olarak konumlanır. Mobile BFF mobile client için optimize: small payload, low chatty (5 endpoint = 1 mobile screen), offline-friendly. Web BFF web için optimize: larger payload, SSR friendly. IoT BFF cihazlar için optimize: minimal byte transfer, binary protokoller (Protobuf, CBOR).
| Boyut | Mobile BFF | Web BFF | IoT BFF | Smart TV BFF |
|---|---|---|---|---|
| Payload size hedefi | 2-15 KB | 30-80 KB | 0,5-2 KB | 10-30 KB |
| API çağrı sayısı/ekran | 1-2 | 3-8 | 1 | 2-4 |
| Protokol | JSON, GraphQL | JSON, GraphQL | Protobuf, CBOR | JSON |
| Caching strateji | Aggressive | Standart | None (push) | Standart |
| Offline desteği | Önemli | Orta | Push only | Düşük |
| Tipik framework | NestJS, Spring | Next.js, Nuxt | Custom (Go, Rust) | Node.js |
Karşılaştırma: BFF vs GraphQL Federation vs API Gateway
BFF, GraphQL Federation ve API Gateway sıklıkla karıştırılan üç pattern. BFF client-specific bir backend; GraphQL Federation client-agnostic schema composition; API Gateway client-agnostic trafik yönetimi. Birbirini dışlamıyor; çoğu kurumsal mimaride üçü birlikte var olur: API Gateway en önde, GraphQL Federation veya BFF arkada, en arkada mikroservisler.
- BFF: Client-specific, frontend ekibi sahibi, aggregation + transformation.
- GraphQL Federation: Client-agnostic, schema composition, single endpoint.
- API Gateway: Client-agnostic, trafik yönetimi, auth, rate limit.
- BFF + GraphQL kombinasyonu: BFF içinde GraphQL Federation client olarak çalışıyor.
İlgili konu: API gateway rehberimizde BFF entegrasyonu ele alındı.
Organizasyonel Sahiplik ve Conway’s Law
BFF’in en kritik tasarım kararı ‘sahiplik’tir. Sam Newman 2025’te açıkça vurguluyor: BFF, frontend ekibinin uzantısıdır, ayrı bir backend ekibinin değil. Eğer BFF’i ayrı bir backend ekibi sahipleniyorsa pattern overengineered hâle gelir ve gerçek değerini üretmez. Conway’s Law (sistem organizasyonu organizasyon yapısını yansıtır) gereği, mobile BFF mobile ekibinin, web BFF web ekibinin sorumluluğunda olmalı.
Operasyon, Edge-Deployed BFF ve Performance
Modern BFF deployment’ları edge’e taşınıyor; Cloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge gibi platformlarda çalışıyor. Bu, BFF’in client’a coğrafi olarak yakın olmasını ve cold start latency’sinin minimize edilmesini sağlıyor. Cloudflare 2025 raporu, edge-deployed BFF’lerde p99 latency’nin geleneksel BFF’e göre %58 azaldığını gösteriyor.
| BFF Deployment | Latency p99 | Cold start | Tipik Maliyet | Vendor |
|---|---|---|---|---|
| Traditional (Kubernetes) | 80-180ms | — | Orta | K8s cluster |
| Serverless (Lambda) | 120-280ms (warm) | 200-800ms | Düşük | AWS Lambda |
| Cloudflare Workers | 15-45ms | 0-5ms | Çok düşük | Cloudflare |
| Vercel Edge Functions | 20-65ms | 0-10ms | Düşük | Vercel |
| Deno Deploy | 18-50ms | 0-5ms | Düşük | Deno |
| AWS Lambda@Edge | 40-120ms | 40-200ms | Orta | AWS |
Sektörel Use Case’ler: E-Ticaret, Banking, Media
E-ticaret platformlarında mobile BFF kategoriler, ürün önerileri, sepet, kullanıcı bilgileri gibi ihtiyaçları tek endpoint’e aggregate ediyor. Türkiye’de bir büyük e-ticaret kurumunda mobile BFF deploy edildikten sonra ürün detay sayfası API çağrı sayısı 7’den 1’e indi, mobile data tüketimi %62 azaldı. Bankacılık mobile app’lerinde BFF, dashboard ekranını oluşturan 12 farklı core sistem çağrısını tek BFF endpoint’inde aggregate ediyor. Media uygulamalarında smart TV BFF’i, geleneksel mobile/web BFF’inden farklı feed format’ları sunuyor.
Kurumsal BFF Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- BFF’in ayrı bir backend ekibine atanması — pattern overengineered hâle geliyor ve değer üretmiyor.
- Mobile ve Web BFF’lerini tek BFF’de birleştirme — her client için ödün veriliyor.
- BFF’in business logic taşımasına izin verilmesi — domain logic ile presentation karışıyor.
- Downstream service contract’larının BFF aracılığıyla maskelenmesi — direct contract evolution kaçırılıyor.
- Edge deployment ihtimam edilmeden geleneksel sunucularda BFF çalıştırılması — latency sürprizi.
- BFF’de caching stratejisinin atlanması — downstream mikroservislere gereksiz çağrılar.
Sonuç
Backend-for-Frontend pattern 2026’da kurumsal frontend stratejisinin merkezinde; mobile API çağrı sayısının %68 düşmesi, payload’ın %53 küçülmesi ve frontend ekibi release hızının 2,4x katlanması açısından kanıtlanmış değer sağlıyor. Doğru sahiplik modeli (frontend ekibinin uzantısı, ayrı backend ekibi değil) kritik; Conway’s Law gereği organizasyonun BFF mimarisine yansıması gerekiyor. Edge-deployed BFF (Cloudflare Workers, Vercel Edge) geleneksel BFF’lere göre p99 latency’yi %58 azaltıyor. Mobile, web, IoT için ayrı BFF’ler; her biri client karakteristiğine optimize. Pilot bir mobile uygulama için BFF deploy edin, kademeli olarak diğer client’lara genişletin. Detaylı kaynak için Sam Newman – BFF Pattern, ThoughtWorks Tech Radar ve Martin Fowler Articles incelenmelidir.
Sıkça Sorulan Sorular
BFF ile API Gateway aynı şey mi?
Hayır. API Gateway client-agnostic trafik yönetimi (auth, rate limit, routing) yapar; BFF client-specific aggregation ve transformation katmanı. Tipik kurumsal mimaride ikisi de var: API Gateway en önde, BFF arkasında. BFF, downstream mikroservisleri çağırırken API Gateway üzerinden geçebilir.
Mobile ve web için ayrı BFF’ler şart mı?
Eğer mobile ve web payload, API çağrı pattern’i veya UX flow’u farklıysa evet, ayrı BFF’ler değerli. Eğer mobile ve web aynı veri ve flow’u kullanıyorsa tek BFF yeterli ve overengineering’ten kaçınmış olursunuz. Çoğu kurumsal projede mobile-first yaklaşımı ayrı BFF’leri haklı kılıyor.
BFF’i frontend ekibi mi backend ekibi mi sahiplenmeli?
Sam Newman’ın 2025 güncellemesinde net olarak vurguladığı gibi: BFF frontend ekibinin uzantısıdır, sahiplik frontend ekibinde olmalı. Ayrı bir backend ekibi BFF’i sahipleniyorsa pattern overengineering tuzağına düşer; gerçek değer üretemez. Frontend ekibi en azından BFF kodunun read+commit erişimine sahip olmalı.
GraphQL kullanırsam BFF’e gerek var mı?
GraphQL Federation BFF’in bazı işlevlerini sağlar (aggregation, client-specific shape) ama hâlâ ihtiyaç durumuna göre BFF değerli olabilir. Karmaşık business logic (örneğin authentication state, A/B testing, feature flag) GraphQL schema’sında değil BFF’te çözülmeli. CNCF 2025 verisi GraphQL + BFF kombinasyonunun en yaygın olduğunu gösteriyor.
BFF performance overhead’i ne kadar?
BFF her client çağrısına +5-15ms latency ekler (downstream çağrı paralelleştirme, transformation). Bu, çoklu downstream çağrılarının client’tan paralel yapılmasının bekleme süresinden çok daha az. Mobile BFF deploy eden ekiplerde ortalama p99 latency’nin azaldığı gözlemleniyor.
Ömer ÖNAL
Mayıs 23, 2026BFF pattern’i kurumsal müşterilerime önerirken her zaman bir uyarı eklerim: ‘BFF aslında bir mikroservis değil, bir frontend uzantısıdır — sahibi frontend ekibi olmalıdır’. Bu sahiplik netliği olmadan BFF, ekstra bir backend katmanı olur ve hızla overengineered hâle gelir. Mobile ve web ekiplerinin ayrı BFF’leri olduğu büyük bir e-ticaret projesinde mobile payload boyutunu %62 düşürdük ve mobile release hızını 2 katından fazla artırdık. — Ömer Önal