Backend For What? Backend For Frontend, BFF.

Published in

Bilişim Hareketi

7 min readApr 10, 2016

Kaynak: Resim https://www.thoughtworks.com/insights/blog/bff-soundcloud blog yazısından alınmıştır, resmi ilgili bloğu yazan lukasz-plotnicki hazırlamış.

“One funny lesson we learned from is that rebranding an existing idea and kind of marketing and selling it back to the people is the key to the getting recognition for SoundCloud’s engineering.” Bora Tunca, SoundCloud

Bora Tunca’nın microchg 2016 konferansındaki sunumunda söylediği yukarıdaki sözün tercümesi şöyle: “Bundan öğrendiğimiz bir tuhaf ders de var olan bir fikri alıp yeni bir isimle markalaştırmanın ve bir nebze pazarlama ve insanlara geri satmanın SoundCloud’un mühendisliğine tanınırlık kazandırmada anahtar konumda olduğudur.”

Biz garip yazılımcıların kaderidir, biz yürürüz ancak altımızdaki zemin daha hızlı kayar, yetişmeye çalışırız. Dün öğrendiğimiz bilgi bugün eskimiştir, geçersiz kalmıştır. Dün problem olarak bellediklerimiz bugün artık problem olmaktan çıkmıştır. Dünkü çözümlerimiz bugünün problemlerini çözmede yetersiz kalmaktadır.

İşin kötü tarafı bugün öğrendiklerimiz de yarın eskiyecek, yarının problemlerine çözüm olma niteliklerini yitireceklerdir. Diğer iş alanlarında bu denli bir devinim, değişim var mı bilmiyorum, ancak bilişim sektörü böyle ve bu alanda çalışan, günceli yakalamaya çalışan herkes için bu durum aşırı zorlayıcı.

Bize okulda öğrenmeyi öğretiyorlar demişti biri bir zaman. İş hayatında da çalıştığımız yerdeki ihtiyaçlara karşılık verebilmek için hızlı öğrenmeyi öğreniyor gibiyiz. O kadar çok teknoloji var ki, bunların hepsinde uzman olmak olanaksız. Mesela sadece Java ekosisteminde Java’nın yanısıra jvm üzerinde çalışan onlarca dil var; Scala, Closure, Groovy, Kotlin, Ceylon… Bir sürü web kütüphanesi var; Spring MVC, JSF ve ilgili kütüphaneler, Apache Wicket, Struts, GWT, Grails, Vaadin. Farklı JS kütüphaneleri var ön yüzde kullanılan; JQuery, ExtJS, Angular, Backbone, Ember, Knockout, React… Farklı şablon dilleri, aynı işi yapan birbirinin muadili tonlarca farklı kütüphane, farklı web geliştirme yaklaşımları, farklı paradigmalar, farklı diller, farklı araçlar, farklı ortamlar, farklı süreçler. Her şirket bunların farklı bir kombinasyonunu kullanıyor. Bir yerde öğrendiğin başka bir yerde ağırlığını yitirebiliyor. Boşuna taş yerinde ağırdır dememişler. Şirketteki ürünlere, kişilere, süreçlere ait tarihsel bilgi birikimi yanı sıra şirkette kullanılan teknoloji kümesinde uzmanlaşmak ve akışkan olarak çalışabilmek de taşın o yerdeki yer çekiminin fazla olmasının sebeplerinden biridir.

Popülaritesi, bilinirliği nerede ne kadardır bilmem ama ben yakınlarda yeni bir kavramla tanıştım: BFF. Backend For Frontend. Yani ön yüz için geliştirilmiş, ön yüze özgü olarak, onun ihtiyaçlarını göz önüne alarak geliştirilmiş sunucu uygulaması. Araştırıp öğrendiklerimi de sizinle paylaşayım istedim.

Kavram SoundCloud tarafından ortaya atılmış. Yeni bir yaklaşım/mimari kalıp olmaktan çok yeni bir isimlendirme. Hikayesi şöyle. SoundCloud’un Ruby on Rails ile yazılmış monolitik bir uygulaması varmış. Bu uygulama içine gömülü bir katman olarak dışa açık bir API bulunuyormuş. Hem SoundCloud’un kendi geliştirdiği mobil/web uygulamalar, hem web uygulamalarında gömülü olarak çalışan küçük uygulamacıklar (web widgets), hem de 3. partiler aynı API’yi kullanıyormuş. Ön tarafta çalışan tüm uygulamaların ortak kullandığı genel amaçlı bir API. Burada karşılaşılan iki ana problem şöyle:

İlk olarak mobil uygulamalar (front-end) bir değişik fonksiyonanlara ihtiyaç duyduğunda ortak API’de bu değişikliği yapmak zaman alıyormuş. Çünkü büyük bir uygulama, bir değişiklik herkes tarafından görülecek ve herkesi etkileyecek, ayrıca API’yi geliştiren ekip ile mobil ekip ayrı dolayısıyla bir iletişim yükünü taşımak zorunda kalıp, yavaş hareket etmek zorunda kalıyorlarmış. API ekibine istek iletilecek, planlama yapılacak, farklı ekiplerden gelen istekler arasında önceliklendirilecek, geliştirilecek, devreye alınacak. Hızlı hareket etmenin, denemeler yapmanın önünde bir engel, yeni özellik eklemek çok kolay değil, süreç uzun ve iletişim sürtünme katsayısı yüksek.
Diğer bir sebep ise genel amaçlı API’nin ön uçta çalışan farklı tipteki uygulamaların ihtiyaçlarına karşılamakta yetersiz kalması. Mesela mobil uygulamalar daha az veri istiyor çünkü ekranlar web uygulamalarına göre küçük, ayrıca iletişim hızı daha yavaş olabiliyor, bant genişliği hassasiyeti var, istek frekansları farklı olabiliyor, ayrıca fonksiyonlar da farklı olabiliyor. Mesela webde ürünler listelenip ardından sipariş akışına girilirken, mobil tarafta önce barkod okutup ardından bu barkoda ait ürünün bulunup sipariş akışına girilmesi gibi bir fonksiyonel farklılık olabiliyor.

Dolayısıyla SoundCloud bir taraftan yeni özellikler için veya bazı ana uygulamadaki bazı özellikleri aktarmak mikroservisler geliştirip modern mimariyi deneyimlerken bir yandan da bu problemlere çözüm bulmaya çalışmışlar. Hem fonksiyon hem de platform farklılığı temelinde özelleşmiş API’ler yazmışlar. İOS/Android dinleyici uygulaması için bir BFF, içerik oluşturma ve yükeleme mobil uygulamalrı için ayrı bir BFF, gömülü web uygulamacıkları için ayrı bir BFF, 3. partilere veya iş ortakları için ayrı BFF ler oluşturmuşlar. İçeride merkezde mikroservis katmanı, onun üstünde çeperde özelleştirmiş API’lerin bulunduğu bir katman. Bu istemci veya fonksiyona göre özelleştirilmiş API’lere de BFF ismini vermişler.

Büyük monolitik uygulamalarına da bir mikroservis gözüyle bakmışlar ve zaman içerisinde oradaki özellikleri yavaş yavaş mikroservislere kaydırmışlar. İstemciler direk arka tarafı görmediği için, BFF ler tarafından içerisi dışarıdan izole edildiği için yavaş yavaş istekleri BFF’ler monolitik uygulamadan mikroservislere kaydırmışlar. Dolayısıyla büyük monolitik uygulama yavaş yavaş küçülmüş, buna boğazını sıkarak öldürmek anlamında Strangler kalıbı deniyormuş. Yani bir uygulamayı yavaş yavaş öldürmek, yok etmek anlamında.

BFF’ler ön uçta çalışan uygulamalara veya fonksiyonlara göre özelleştirilmiş olduğu ve herkesin derdine derman olmaya çalışmadığı için daha küçük ve kendi problem alanına odaklanmış oluyormuş. Ayrıca ön yüz ile BFF uygulamasını aynı ekibin geliştirmesi gerekiyormuş yoksa bir anlamı kalmıyormuş. Hem Martin Fowler hem de Sam Newman’ın makalelerinde organizasyon yapısı ile uygulama mimarisi arasında sıkı bir bağ olduğuna dair Conway kanununa sık sık atıf yapılmış. Organizasyon yapısının ve servislerin sahipliğinin kimde olduğunun hayati önemi olduğunun sık sık altı çizilmiş.

Bora Tunca’nın ifadesiyle SoundCloud kendi mimarisini oluştururken, Netflix’ten esinlenmiş, onu örnek almış. Yani tekerleği yeniden keşfetmemiş.

API Gateway/API Facade/BFF eş/yakın anlamlı kavramlar imiş. Tek bir API varsa genel amaçlı API (general purpose API Gateway) oluyor, istemcilere göre veya fonksiyonlara göre özelleştirince, istemciye veya fonksiyonlara göre özelleştirilmiş API’ler (client-specific APIs veya BFFs) oluyor.

Tabi zamanla, hiç bir şey durduğu yerde durmuyor, aynı kavramın ima ettiği fonksiyonalite kümesine yeni özellikler eklenebiliyor veya bu kümedeki fonksiyonlar buradan çıkarılabiliyor. Bu da bir kavramla neyi ifade ettiğimizi iletmede güçlüklerle karşılaşmamıza sebep olabiliyor. Örneğin SoundCloud mikroservislerden bilgileri alıp toplama işini önce BFF’lerin içinde yapıyormuş, sonra kod tekrarı oluyor diye bu işi ayrı mikroservisler oluşturup onlara havale etmiş.

İstemciye özgü veya fonksiyon grubuna özgü bir API geliştirme ihtiyacının yanısıra, mikroservislerin popülerleşmeye başlamasıyla birlikte bu mimari kalıp da tekrar gün yüzüne çıkmış.

Mikroservis, büyük bir uygulama yerine, küçük küçük uygulamalara deniyor. Bu küçük uygulamalar/servisler, ilgili iş alanındaki fonksiyonları anlamlı bir bütünlük oluşturacak şekilde küçük küçük gruplara ayırarak oluşturuluyor. Küçüklük/büyüklük biraz göreceli oluyor doğal olarak. Örnek olarak SoundCloud’ı alacak olursak en başta tek bir monolitik uygulamaları varmış. Ardından 2013'te 20 civarında mikroservisleri olmuş. Sonra yavaş yavaş artmış ve şimdi 120 civarında mikroservisten bahsediyorlar. Kullanıcılar, şarkılar, resimler, istatistikler, öneriler, müzik listeleri, kimlik doğrulama, coğrafi konum belirleme, sevilenler, mesajlar, arama vb. gibi farklı fonksiyonel grupları birer servise dönüştürmüşler.

Mikroservislerin dertleri bu metnin ana odak noktası olmadığından, bu problemlerden BFF’ler ile çözülenlerine değinmek lazım. Bilgiyi bu şekilde küçük parçalara ayırıp dağıtmak beraberinde uğraşılması ve çözülmesi gereken başka problemleri getiriyor.

http://microservices.io/patterns/apigateway.html sitesinde amazon örneği verilmiş. Amazon’da satılan bir kitaba ait bir sayfada; kitaba ait bilgiler, yazara ait bilgiler, kitabın stok bilgisi, satın alma seçenekleri, benzer ürünler, yorumlar vb bir sürü bilgi bulunuyor. Amazon mikroservis mimarisini kullandığında bu bilgileri getirmek için ayrı ayrı servislere gitmek ve sayfaya getirmek durumunda. Bu da bir sürü istek demek. Bunun yerine araya bir toplayıcı (aggregator) katman koyup bu istekleri tek bir istekte isteyip, toplayıcı uygulama içerisinde bunları alttaki mikroservislerden paralel bir şekilde isteyip cevapları toplayarak birleştirip istemciye göndermek de bir çözümlerden biri.

Sam Newman da küçük uygulamalar için bu mimari kalıbın kullanılabileceğini, ancak iş mikroservislere gelince bu mimarinin çok önemli olduğunu belirtmiş. Yukarıdaki Amazon örneğine benzer bir örnekle toplayıcı bir uygulamaya/servise olan ihtiyaca vurgu yapmış.

SoundCloud toplayıcı kısmını öncelikle BFF uygulamarında yapmış, sonra bakmış ki aynı servislerden aynı kaynakları/bilgileri aynı şekilde alıp aynı şekilde birleştirip iletiyorlar bu rahatsız etmiş, bunu ortak kütüphanede yapmak da servisler arası / ekipler arası bağımlılıkları artırdığından ayrı bir toplayıcı servis olarak konumlandırmışlar. En altta temel çekirdek mikroservisler, üstünde katma değerleri mikroservisler ve tabi toplayıcı servisler en üstte de BFF uygulamalarının olduğu bir katman olmak üzere sunucu tarafında üç katmanlı bir yapı kullanmaya başlamışlar.

Özetlemek gerekirse;

Çözüm aranan problemler neler? (aynı anda veya ayrı ayrı):

Mikroservislerin doğası itibariyle bilgilerin küçük parçalara bölünmesi ve ön taraftaki uygulamalardaki ekranlarda/senaryolarda kullanılmak için bu bilgilerin birleştirilmesi gerekliliği
İstemcilerin veya ön uçta çalışan uygulamaların (mobil/web/mobil-web/gömülü/3.parti) farklı olması ve tek bir gömleğin kimine büyük kimine küçük gelmesi
Özellikle büyük ölçekli şirketlerde büyük bir uygulamanın API katmanının bir ekibin sorumluluğunda olması, bunun da iletişim yükü ve sürtüşme getirmesi ve hızlı hareket etmeyi engellemesi, ön uçtaki uygulamayı yazanların hızlıca bir şeyi denemelerini zor hale getirmesi
Alttaki mikroservislerde ortak olarak yapılan bazı şeyleri tekrarların önüne geçmek için ayrı bir katmanda bir kerede yapılma ihtiyacı (cross-cutting concerns). Mesela kimlik doğrulama, http başlığına bilgi koyma, güvenlik, loglama vb.
İçeriyi dışarıdan yalıtma ve monolitik uygulamayı yavaş yavaş mikroservislere dönüştürme ihtiyacı

BFF çözümünün getirebileceği problemler neler?: (aynı anda veya ayrı ayrı)

Uygulama sayısının artması bunun bakım ve operasyon maliyetlerini artırması
Mimari karmaşıklığın artması
Eklenecek ayrı bir katmanın ağ isteklerinde gecikme yaratma ihtimali
Aynı şeylerin faklı BFF lerde tekrar tekrar yapılıyor olması ve kod tekrarı. Bundan kaçınmak için kullanılabilecek ortak kütüphane kullanımının getirebileği ayrı problemler.

Artur Ejsmont, “Girişim şirketlerindeki mühendisler için ölçeklenebilir web” kitabında şöyle diyor: “En nihayetinde yeterli karmaşıklık ile aşırı mühendislik arasındaki çizgiyi çizecek olan yazılım mühendisi olarak sizsiniz. Bu zor bir görev, ve burada siyah ve beyaz yok. Bu tamamen grinin tonlarında oynanan bir değiş tokuşlar oyunu. ”

Yazılım mühendisliği değiş tokuşlar oyunu. Bir şeyi kazanırken bir şeyi feda ediyoruzdur. Bir problem için geliştirdiğimiz bir çözüm beraberinde başka problemler getiriyor olabilir. Mesela CAP teoremi diyorlar, “C”, “A”, “P”. Üçünden ikisini al. Hepsini birden alamıyorsun. Birini feda etmen lazım. Ekip sayısına, büyüklüğüne, organizasyon yapısına, alışkanlıklara, kişilerin konfor alanlarına, uygulama büyüklüğüne, ilgili iş alanının oturmuş veya yeni doğmakta olup olmadığına göre ve yine sayılabilecek daha bir sürü değişkene bağlı oluyor yapacağımız tercihler.

Bir tercih yaptığında neyi feda ettiğini hatırla.

Notlar:

Resim https://www.thoughtworks.com/insights/blog/bff-soundcloud blog yazısından alınmıştır, resmi ilgili bloğu yazan lukasz-plotnicki hazırlamış.

Kaynaklar:

Backend For What? Backend For Frontend, BFF.

Written by Süleyman Fazıl Yeşil