Backend for Frontend (BFF) Nedir?

Backend for Frontend (BFF) olarak bilinen yapı, belirli bir ön yüz (frontend) için özel olarak oluşturulmuş bir arka uç (backend) hizmetidir. Her istemcinin (web, iOS, Android, üçüncü taraf) aynı genel amaçlı arka uç ile konuşması yerine, her biri mikro hizmetlerinizden gelen verileri toplayıp arayüzün ihtiyaç duyduğu şekle dönüştüren kendi sunucu tarafı katmanına sahip olur.

Sam Newman, 2015 yılında SoundCloud'da yapılan çalışmalardan yola çıkarak bu kalıbı isimlendirdi ve popülerleştirdi. On yıldan fazla bir süre sonra bile BFF kalıbı, birden çok istemci uygulaması kullanan ekipler için standart bir araç olmaya devam ediyor ve Microsoft bunu temel bir bulut mimarisi kalıbı olarak belgeliyor.

BFF'nin çözdüğü sorun

Tek bir web uygulaması ve tek bir arka uç ile başlayan bir sistem hayal edin. Arka uç REST uç noktaları sunuyordu, web uygulaması bunları kullanıyordu ve hayat basitti. Sonra şirket bir mobil uygulama çıkardı. Ardından bir iş ortağı entegrasyonu. Sonra bir akıllı saat widget'ı. Birdenbire dört çok farklı istemci aynı arka uçtan veri çekiyor ve o arka uç herkesi aynı anda memnun etmeye çalışıyor.

Bu durum iki tekrarlayan sorun yaratır.

Gereğinden fazla veya gereğinden az veri çekme (Over-fetching ve under-fetching). Genel amaçlı bir uç nokta, sabit bir veri yapısı döndürür. Bir masaüstü paneli, sipariş geçmişi, öneriler ve hesap ayarlarıyla birlikte tüm müşteri kaydını tek bir yanıtta isteyebilir. Zayıf hücresel bağlantıya sahip bir mobil uygulama ise yalnızca üç alan ve başka hiçbir şey istemez. Her ikisi de aynı uç noktaya istek attığında, bunlardan biri yanlış miktarda veri alır. Mobil istemci ya atmak zorunda kalacağı şişirilmiş bir yükü indirir (gereğinden fazla veri çekme) ya da ihtiyaç duyduğu veriyi bir araya getirmek için birkaç ek gidiş-dönüş yapmak zorunda kalır (gereğinden az veri çekme).

Çok konuşkan istemciler (Chatty clients). Bir arka uç bir ekrana özel olarak tasarlanmadığında, istemci birçok çağrı yaparak bunu telafi eder. Profil verilerine, bildirim sayısına ve bir akışa ihtiyaç duyan bir mobil ana ekran, üç veya dört mikro hizmete üç veya dört ayrı istek gönderebilir, ardından sonuçları cihazda bir araya getirebilir. Her fazladan gidiş-dönüş, gecikmeye ve pil tüketimine mal olur ve orkestrasyon mantığı, test edilmesi ve sürüm oluşturulması zor olan istemciye sızar.

Temel gerilim, teknik olduğu kadar organizasyoneldir de. Paylaşılan bir arka uç, her ön yüz ekibinden gelen birbiriyle çelişen taleplere sahiptir. Bir ekibin yaptığı bir değişikliğin, dağıtımdan önce diğer tüm ekiplerin ihtiyaçlarına göre doğrulanması gerekir; bu da arka ucu bir darboğaza ve ekipler arası sürtüşme kaynağına dönüştürür.

BFF kalıbı nasıl çalışır

BFF kalıbı, bir ön yüz ile aşağı akış hizmetleriniz arasında yer alan ince bir sunucu tarafı katmanı sunar. Her arayüz kendi arka ucuna sahip olur.

[ Web uygulaması ] ---> [ Web BFF ] ---
[ iOS uygulaması ] ---> [ iOS BFF ] -----> [ Mikro hizmetler ]
[ Android uygulaması ] ---> [ Android BFF ] ---/

Her BFF, istemcisi için üç iş yapar:

1. Toplama (Aggregate). Ekranın ihtiyaç duyduğu aşağı akış mikro hizmetlerini çağırır ve yanıtlarını birleştirir, böylece istemci beş yerine tek bir istekte bulunur. Bu, tek bir kullanıcı deneyimine uygulanan API toplama işlemidir. Bu fikrin genel versiyonunu istiyorsanız, API toplayıcı kalıbı hakkındaki açıklayıcı yazımıza bakın.
2. Yeniden Şekillendirme (Reshape). Alanları kırpar, şeyleri istemci dostu terimlerle yeniden adlandırır, iç içe yapıları düzleştirir ve değerleri arayüzün beklediği şekilde biçimlendirir. Mobil BFF yalın yükler döndürür; masaüstü BFF zengin yükler döndürür.
3. Çevirme (Translate). Sayfalandırma stratejisi, o istemciye göre ayarlanmış yanıt önbelleğe alma ve protokol seçimleri gibi istemciye özgü endişeleri, bu kararları aşağıdaki paylaşılan hizmetlere zorlamadan ele alır.

Aşağı akış mikro hizmetleri genel amaçlı ve ön yüzden bağımsız kalır. Temiz, yeniden kullanılabilir yetenekler sunarlar. BFF, istemciye özgü şekillendirmenin yaşadığı yerdir; bu da bu mantığı hem mikro hizmetlerden hem de istemci uygulamasından uzak tutar. Temel hizmet katmanına yeniyseniz, mikro hizmetler ile API'ler karşılaştırmamız ve monolitten mikro hizmetlere geçiş hakkındaki genel bakışımız bağlamı oluşturur.

Her istemci deneyimi için bir BFF

Newman'ın temel rehberliği kısadır: bir deneyim, bir BFF. iOS ve Android uygulamalarınız anlamlı derecede farklı deneyimler sunuyorsa, her birine kendi BFF'sini verin. Bir web uygulaması ve bir mobil uygulama birbirinden ayrılıyorsa, aynı kural geçerlidir.

Kuralın amacı, her BFF'yi odaklanmış tutmaktır. Tek bir BFF, farklı ihtiyaçları olan iki istemciye hizmet vermeye çalıştığı anda, koşullu mantık biriktirmeye başlar ("mobilse bunu döndür; web ise şunu döndür") ve tüm aynı koordinasyon sorunlarıyla birlikte genel amaçlı bir arka uca geri dönersiniz. Odaklanmış bir BFF küçük kalır, bu da tüm kalıbın karşılığını vermesini sağlayan özelliktir.

Newman'ın SoundCloud'dan aldığı mantıklı bir istisna vardır: bir ekip, neredeyse aynı deneyimi paylaşan iOS ve Android uygulamaları gibi iki benzer istemciye sahip olduğunda, tek bir mobil BFF'yi aralarında paylaşmak makul olabilir. Belirleyici faktör platform adları değil, sahiplik ve benzerliktir. Kural bir varsayılan değerdir, bir yasa değildir.

Sahiplik ön yüz ekibine aittir

BFF, platform ekibinin oluşturup teslim ettiği bir katman değildir. İstemciye sahip olan ön yüz ekibi, kendi BFF'sine de sahiptir. Bu, kalıbın çalışmasını sağlayan ikinci yarıdır.

Ön yüz ekibi BFF'ye sahip olduğunda, sürüm yayınlama hızını kontrol eder, dilini ve çalışma zamanını seçer, birikmiş işini önceliklendirir ve istemciye ve destekleyici hizmetine yapılan değişiklikleri birlikte yayınlar. Yeni bir birleştirilmiş uç nokta gerektiren bir kullanıcı arayüzü değişikliği, ayrı bir arka uç ekibine talep açmayı ve o ekibin kuyruğunu beklemesini gerektirmez. Acıyı hisseden ekip, çözüme sahiptir.

Bu özerklik gerçek kazanımdır. BFF, sınırları hareket ettirir, böylece istemciye özgü kararlar, istemciden sorumlu kişiler tarafından alınır, ki bu da API liderliğindeki bağlantı düşüncesinin "deneyim" katmanını tam olarak buraya koyduğu yerdir.

BFF ve API ağ geçidi karşılaştırması

Bu, çoğu ekibin takıldığı bir karşılaştırmadır, çünkü bir BFF ve bir API ağ geçidi bir diyagramda benzer görünür. Her ikisi de istemciler ve hizmetler arasında yer alır. Her ikisi de yönlendirme ve toplama yapabilir. Ancak farklı soruları yanıtlarlar.

Bir API ağ geçidi, tüm trafik için kesişen endişeleri ele alan genel amaçlı bir giriş noktasıdır: kimlik doğrulama, hız sınırlama, yönlendirme, TLS sonlandırma ve istek günlüğü. Bir platform veya altyapı ekibi tarafından sahiplenilir ve kasıtlı olarak istemciden bağımsızdır. Tek bir ağ geçidi herkese aynı şekilde hizmet verir.

Bir BFF ise tam tersidir. Tasarımı gereği istemciye özeldir, bir ön yüz ekibine aittir ve tüm amacı her arayüz için farklı olmaktır. Paylaşılan bir darboğaz değil, bir istemcinin yük şekillendirmesinin yaşadığı yerdir.

Bu ikisi rakip değildir. Ortak bir üretim düzeninde, bir API ağ geçidi önde yer alır, tüm trafik için kimlik doğrulama, hız sınırlama ve izlemeyi yönetir ve ardından her istemciyi ağ geçidinin arkasındaki özel BFF'sine yönlendirir. Microsoft'un referans mimarisi tam da bunu gösterir: kesişen endişeleri yöneten bir ağ geçidi ve arkasında istemci başına sunucusuz bir BFF. İstemciler arasında aynı olan şeyler için ağ geçidini, farklı olan şeyler için ise bir BFF kullanın. (Bu karşılaştırmanın derinlemesine versiyonunu ayrı bir makalede ele alıyoruz; burada farklı katmanlarda yer aldıklarını ve farklı ihtiyaçlara cevap verdiklerini bilmek yeterlidir.)

Çevredeki ağ geçidi ortamı için şu yayınlanmış karşılaştırmalar yardımcı olur: API yönetimi ve API ağ geçidi, API ağ geçidi ve yük dengeleyici ve hizmet ağı ve API ağ geçidi.

BFF ne zaman kullanılır

Bu koşullar sağlandığında kalıp değerini ortaya koyar:

• Birden çok, gerçekten farklı istemciniz var. Web, mobil ve bir iş ortağı entegrasyonu, her biri farklı veri ihtiyaçlarına sahip. Deneyimler ne kadar farklılaşırsa, bir BFF o kadar çok yardımcı olur.
• Paylaşılan bir arka uç darboğaz haline geldi. Her ön yüz değişikliği ekipler arası müzakereyi zorluyorsa, istemciye özel şekillendirmeyi ekip başına BFF'lere bölmek koordinasyon yükünü ortadan kaldırır.
• İstemci için optimize edilmiş yükler istiyorsunuz. Mobil, yalın yanıtlar ve agresif önbellekleme ister; masaüstü, zengin birleştirilmiş veriler ister. Bir BFF, her birini ödün vermeden optimize etmenizi sağlar.
• Bir dil, bir ön yüze daha iyi uyar. Bir ekip, diğer BFF'lerin kullandığından bağımsız olarak, istemcisine uygun çalışma zamanında kendi BFF'sini oluşturabilir.

BFF ne zaman kullanılmaz

Kalıp ücretsiz değildir ve karşılığını vermeden maliyet eklediği açık durumlar vardır:

• Yalnızca tek bir istemciniz var. Tek bir arayüzle, bir BFF sadece fazladan bir adımdır. Normal bir arka uç oluşturun.
• İstemcileriniz aynı istekleri yapıyor. Web ve mobil neredeyse aynı verileri aynı şekilde istiyorsa, ayrı BFF'ler faydasız yere çabayı tekrarlar. Bunun yerine birleştirin.
• GraphQL zaten şekillendirme sorununuzu çözüyor. GraphQL ile her istemci, tek bir uç noktadan tam olarak ihtiyaç duyduğu alanları sorgular; bu, istemci başına bir arka uç olmadan aşırı ve yetersiz veri çekmeyi büyük ölçüde kapsar. Ön yüze özel çözümleyicilere sahip bir GraphQL katmanınız varsa, ayrı bir BFF katmanı genellikle bir değer katmaz. Bir BFF katmanı eklemeden önce GraphQL'in ne olduğunu öğrenerek uygun olup olmadığını değerlendirin.
• Bir ağ geçidi ve mikro hizmetler yeterli. Daha basit sistemler için, iyi tasarlanmış mikro hizmetlerin önündeki bir API ağ geçidi, özel bir istemci başına katman olmadan kabul edilebilir sonuçlar sağlayabilir.

Dürüst dezavantajları

Bir BFF doğru çağrı olsa bile, gerçek maliyetlere katlanırsınız. Gözü açık olmak, kalıbı iyi kullanmanın bir parçasıdır.

Kod tekrarı. Bu, en önemli değiş tokuştur ve Microsoft'un belgeleri bunu doğrudan belirtir. Üç BFF'nin de aynı kimlik doğrulama kontrolünü çağırması veya aynı tarihi aynı şekilde biçimlendirmesi gerektiğinde, bu mantık genellikle üç kez yazılır. Özelleştirme karşılığında tekrarı kabul edersiniz. Çözüm disiplindir: gerçekten paylaşılan mantığı BFF'lerin içe aktardığı kütüphanelerde tutun ve BFF'nin kendisini istemciye özgü şekillendirmeye ayırın. Gerçek kesişen endişeleri (kimlik doğrulama, hız sınırlama, izleme) her BFF'de yeniden uygulamak yerine ağ geçidine taşıyın.

İşletilecek daha fazla hizmet. Her BFF, kendi yaşam döngüsü, hattı, nöbet rotasyonu ve güvenlik yüzeyine sahip ayrı bir dağıtılabilir birimdir. Daha fazla hizmet, daha fazla operasyonel yük anlamına gelir.

Fazladan bir ağ atlaması. İstemciler artık hizmetlerle doğrudan konuşmaz. BFF fazladan bir atlama ekler ve bu da gecikmeyi artırabilir. Genellikle değerli bir değiş tokuştur, çünkü BFF birkaç istemci gidiş-dönüşünü ortadan kaldırır, ancak bu ölçülmesi gereken bir maliyettir, varsayılacak bir şey değildir.

BFF'nin şişme riski. Bir BFF birden çok istemciye hizmet vermeye başlarsa veya mikro hizmetlere ait iş mantığını absorbe ederse, kaçmaya çalıştığınız genel amaçlı arka uca doğru geri kayar. İnce tutun.

BFF sözleşmelerini Apidog ile senkronize tutma

Uygulamada BFF'leri çalıştırmanın zor kısmı sözleşmelerdir. Her BFF, kendi istemciye yönelik API'sini sunar ve aynı zamanda altındaki mikro hizmetlerin sözleşmelerine bağımlıdır. Bu, farklı katmanlara sahip ekipler arasında çok sayıda hareketli arayüz anlamına gelir ve aralarındaki sapma, hataların ve bozuk istemcilerin kaynağıdır.

Apidog iş akışına işte burada girer. Apidog bir API tasarım, test, modelleme ve dokümantasyon platformudur, bu nedenle her BFF'nin API sözleşmesi, hem ön yüz hem de arka uç ekiplerinin birlikte çalışabileceği tek bir yere sahiptir:

• Önce sözleşmeyi tasarlayın. Her BFF uç noktasını ve onun istek ve yanıt şemasını Apidog'un görsel tasarımcısında OpenAPI kullanarak tanımlayın, böylece kod yazılmadan önce istemciye yönelik yapı üzerinde anlaşmaya varılır. Bu, BFF katmanına uygulanan önce sözleşme yaklaşımıdır ve API sözleşmesini açık tutar.
• Var olmadan önce modelleyin. Ön yüz ekibi, sözleşme üzerinde anlaşmaya varıldığı gün, BFF veya onun aşağı akış hizmetlerinin hazır olmasını beklemeden, BFF'nin bir Apidog akıllı modeline karşı geliştirme yapmaya başlayabilir.
• Sözleşmeyi test edin. Apidog'un otomatik testleri ve iddiaları, her BFF'nin istemcisinin beklediği birleştirilmiş, yeniden şekillendirilmiş yükü döndürdüğünü doğrular ve bunlar CI'a entegre edilerek bir BFF yanıtını bozan bir aşağı akış değişikliğinin erken yakalanmasını sağlar.
• Her iki taraf için belgeleyin. Apidog, sözleşmeden etkileşimli belgeleri otomatik olarak oluşturur, böylece BFF'nin API'sini okuyan ön yüz ekibi ve altındaki hizmetlere sahip arka uç ekibi tek bir doğru kaynaktan yararlanır.

Kapsam hakkında net olmak gerekirse: Apidog sizin BFF'nizi oluşturmaz, barındırmaz veya çalıştırmaz ve bir API ağ geçidi değildir. Her BFF'nin arkasında durduğu API sözleşmesini tasarladığınız, modellediğiniz, test ettiğiniz ve belgelediğiniz yerdir; bu da BFF'ler geliştikçe ön yüz ve arka uç ekiplerini senkronize tutar. Her BFF'yi kararlı, iyi belgelenmiş bir sözleşmeye sahip bir ürün olarak ele almak, kalıbı sürdürülebilir kılan şeydir.

Sıkça Sorulan Sorular

BFF bir mikro hizmet midir? BFF bir sunucu tarafı hizmetidir ve bir mikro hizmet kurulumunda genellikle öyle çalışır. Ancak görevi tipik bir mikro hizmetten farklıdır. Bir mikro hizmet bir iş yeteneğine sahiptir ve istemciden bağımsız kalır; bir BFF ise bir istemcinin deneyimine sahiptir ve o istemci için bu mikro hizmetleri toplamak ve yeniden şekillendirmek için vardır. Bu, bir iş yeteneği hizmeti değil, bir deneyim katmanı hizmetidir.

Kaç tane BFF'ye sahip olmalıyım? Varsayılan olarak, her farklı istemci deneyimi için bir tane: web için bir, iOS için bir, Android için bir vb. Yalnızca tek bir ekip, ihtiyaçları neredeyse aynı olan istemcilere sahip olduğunda ikisini birleştirin. Bir BFF, istemci başına koşullu mantık biriktirmeye başladığında daha fazla ayırın.

GraphQL, BFF kalıbının yerini alabilir mi? Yük şekillendirme kısmı için evet, alabilir. GraphQL, her istemcinin tek bir uç noktadan tam olarak ihtiyaç duyduğu alanları talep etmesine olanak tanır, bu da istemci başına bir arka uç olmadan aşırı ve yetersiz veri çekmeyi kapsar. Ön yüze özel çözümleyicilere sahip bir GraphQL'iniz varsa, ayrı bir BFF katmanı genellikle pek bir değer katmaz. Paylaşılan bir GraphQL sunucusunun kolayca sağlayamayacağı istemci başına orkestrasyon, protokol çevirisi veya çalışma zamanı seçeneklerine ihtiyacınız olduğunda BFF'ler yine de yardımcı olur.

BFF ve API ağ geçidini birlikte kullanabilir miyim? Evet, ve bu yaygın bir durumdur. API ağ geçidi, kimlik doğrulama, hız sınırlama ve izleme gibi tüm istemciler arasında paylaşılan endişeleri ele alır ve trafiği doğru BFF'ye yönlendirir. Her BFF, istemcisine özgü olanı halleder. Farklı katmanlarda yer alırlar ve farklı işler yaparlar.

BFF'nin sahibi kim olmalı? İstemcinin sahibi olan ön yüz ekibi. Bu sahiplik, kalıbın merkezindedir. Ekibin kullanıcı arayüzü değişikliklerini ve destekleyici uç noktaları birlikte yayınlamasına, kendi çalışma zamanını seçmesine ve ayrı bir arka uç ekibinin kuyruğunu beklemeden hareket etmesine olanak tanır.

BFF gecikme ekler mi? Bir ağ atlaması ekler, ki bunun bir maliyeti vardır. Pratikte genellikle toplam istemci gecikmesini azaltır, çünkü birkaç istemci-hizmet gidiş-dönüşünü tek bir istemci-BFF isteğiyle değiştirir ve BFF'nin hizmetleri onlara yakın bir yerde paralel olarak çağırmasına olanak tanır. Her iki durumda da varsayımda bulunmak yerine iş yükünüz için bunu ölçün.