--- title: "BFF Pattern: Mobil ve Web İçin Ayrı API Katmanı" description: "Mobil ve web için ayrı API katmanları: tek API'yi her istemciye uydurmanın gizli maliyeti ve BFF'in ne zaman gerçekten gerektiği." url: https://sade.dev/tr/notes/bff-backend-for-frontend/ lang: tr author: "Muhammet Şafak" published: 2026-07-04 updated: 2026-09-06 section: Note tags: ["architecture","api","bff"] summary: "Tek bir genel API'yi her istemciye uydurmanın bedeli over-fetching, chatty akış, koşullu alanlar ve web ile mobili tek kontrata kilitleyen bir versiyonlama düğümüdür. BFF bu faturayı istemci başına ince bir uyarlama katmanıyla keser — agregasyon ve yanıt şekillendirme, asla iş kuralı değil. Katmanı haklı çıkaran şey istemci sayısı değil, istemciler arasındaki mesafedir." --- # BFF Pattern: Mobil ve Web İçin Ayrı API Katmanı > Tek bir genel API'yi her istemciye uydurmanın bedeli over-fetching, chatty akış, koşullu alanlar ve web ile mobili tek kontrata kilitleyen bir versiyonlama düğümüdür. BFF bu faturayı istemci başına ince bir uyarlama katmanıyla keser — agregasyon ve yanıt şekillendirme, asla iş kuralı değil. Katmanı haklı çıkaran şey istemci sayısı değil, istemciler arasındaki mesafedir. Bir mobil uygulamanın tek bir ana ekranı çizmek için API'ye dokuz ayrı istek attığını gördüm. API aslında web için tasarlanmıştı; mobil, web'in böldüğü veriyi parça parça toplayıp ekranda birleştiriyordu. Her açılış dokuz round-trip — üstelik mobil ağ koşullarında. Bu, "tek API herkese yeter" varsayımının faturasıydı. BFF — Backend for Frontend — tam da bu faturayı kesmek için var. ## BFF nedir BFF, her istemci türü için ince ve ona özel bir API katmanıdır. Web'in kendi BFF'i, mobilin kendi BFF'i olur. Her biri arkadaki asıl servisleri/domain'i çağırır, ama yanıtı kendi istemcisinin ekranına göre şekillendirir. Asıl iş mantığı BFF'te değildir. BFF sadece bir **uyarlama katmanı**: agregasyon yapar, gereksiz alanı kırpar, istemcinin tek ekranda ihtiyaç duyduğu şeyi tek yanıtta toplar. ## Tek API'yi herkese uydurmanın gizli maliyeti Tek bir genel API, zamanla iki istemciyi de tam memnun edemez: - **Over-fetching.** Mobil, 40 alanlı bir kullanıcı nesnesi indirir, 4'ünü kullanır. Geri kalanı boşa giden bant genişliği ve pil. - **Chatty akış.** Web'in normal bulduğu "önce listeyi çek, sonra her satır için detay çek" akışı, mobil ağda dokuz round-trip'e dönüşür. - **Koşullu alanlar.** Yanıt `if mobile then ... else ...` ile dallanmaya başlar. Tek endpoint, iki istemcinin gereksinimini aynı anda taşımaya çalışır ve ikisinde de orta karar bir iş çıkarır. - **Versiyonlama düğümü.** Web için yapılması gereken bir değişiklik, mobilin yayınlanmış sürümünü kırma riski taşır. İki istemci tek kontrata kilitlenir. Bu maliyetler tek tek küçük görünür; toplamı bir mimari problemdir. ## BFF ne zaman gerekli? BFF, istemcilerin ihtiyacı **gerçekten** ayrıştığında gerekçelidir: - Mobil ile web belirgin biçimde farklı ekranlara, farklı veri şekillerine ihtiyaç duyuyor. - Mobil ağ ve pil kısıtları, round-trip sayısını ve payload boyutunu birinci sınıf bir kaygı yapıyor. - İstemciler farklı tempoda yayınlanıyor — mobil sürümü mağaza onayına takılıyken web her gün deploy ediliyor; tek kontrat ikisini birbirine kilitliyor. Bu farklar varsa, her istemciye kendi BFF'ini vermek, tek API'yi sürekli ikisine birden uydurmaya çalışmaktan ucuzdur. ## BFF ne zaman gereksiz? Tek bir istemciniz varsa BFF, çözdüğünden fazla katman ekler — sadece fazladan bir sıçrama. İki istemciniz var ama ikisi de neredeyse aynı veriyi aynı şekilde istiyorsa, yine gereksiz. BFF'i haklı çıkaran şey istemci sayısı değil, istemciler **arasındaki farktır**. Fark yoksa ayrı katman da olmamalı — bu, [spekülatif genelliğin](/tr/journal/ileride-lazim-olur-kodunun-faturasi) API katmanındaki hâli olur. ## BFF mikroservis değildir Sık karışan nokta: BFF eklemek sizi dağıtık mimariye sokmaz. BFF bir sunum/agregasyon katmanıdır, bir domain servisi değil. İçine iş kuralı koymak, kuralı istemci sayısı kadar kopyalamak demektir. BFF'in mikroservisle tek ilişkisi şu: ikisi de "ayrı bir deployable'a değer mi?" sorusunu sorar. Cevap çoğu zaman "hayır" — [mikroservise geçiş kararındaki](/tr/journal/mikroservise-ne-zaman-gecerim) ölçülmüş-sinyal eşiği burada da geçerli. ## Hafif başlayın "BFF" demek, ayrı bir sunucu kurmak demek zorunda değil. Aynı monolit içinde: - İstemci başına bir route namespace — `routes/web-api.php`, `routes/mobile-api.php` — her biri kendi controller'larıyla, kendi yanıt şekliyle. - Ya da tek bir GraphQL katmanı: her istemci ihtiyacı kadarını sorgular, over-fetching kendiliğinden çözülür. Asıl fikir bir kutu değil, bir sınırdır: istemciye özel uyarlamayı tek bir yerde toplayın, domain'i ondan temiz tutun. Ayrı bir deployable'a ancak [ölçülmüş bir sinyal](/tr/journal/mikroservise-ne-zaman-gecerim) zorladığında geçin. --- BFF, "her istemci aynı API'yle idare etsin" inadının panzehiridir — ama yalnızca istemciler gerçekten ayrıştığında. Fark yoksa katman da olmamalı. Katmanı ekleyen şey istemci sayısı değil, aralarındaki mesafedir. ## Sık sorulanlar **BFF ne zaman gereksizdir?** Tek bir istemci varsa BFF çözdüğünden fazla katman ekler — sadece fazladan bir sıçrama. İki istemci varsa ama ikisi de neredeyse aynı veriyi aynı şekilde istiyorsa yine gereksizdir: BFF'i haklı çıkaran şey istemci sayısı değil, istemciler arasındaki farktır. **BFF bir mikroservis midir?** Değildir. BFF bir sunum ve agregasyon katmanıdır, bir domain servisi değil; eklemek sizi dağıtık mimariye sokmaz. İçine iş kuralı koymak, kuralı istemci sayısı kadar kopyalamak demektir. Mikroservisle tek ortak sorusu şudur: bu, ayrı bir deployable'a değer mi? ## Kaynaklar - [Pattern: Backends For Frontends](https://samnewman.io/patterns/architectural/bff/) — Sam Newman - [Backends for Frontends pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends) — Microsoft Azure Architecture Center