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 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 ö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 topla, domain’i ondan temiz tut. Ayrı bir deployable’a ancak ölçülmüş bir sinyal 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.