Backend for Frontend (BFF)
Assalamu Alaykum bugun BFF arxitektura patterni haqida gaplashamiz u nimaga kerak va qaysi o`rinlarda foydaliligini bilib olamiz.
Note : BFF bu yerda best friend forever emas !!!
BFF nimaga kerak ?
BFF monolitda
Buni misol bilan boshlaymiz har doimgidek siz elektron magazin egasi siz va sizda oddiy infrastruktura bor yani kompyuterda ishlaydigan websayt va oddiy monolit backend .
Shu elektron magazindan biror bir API ko`ramiz
GET v1/products/123
bu API quyidagi javobni qaytaradi :
{
"name": "Telefon",
"price": 600,
"description":"...",
"variants": ["blue", "black"] ,
"reviews" : [...],
...
}
Ko`rib turganingizdek bu bitta API javobida faqatgina bir sahifani ko`rsatish uchun shuncha ma’lumot berilmoqda.Buning yordamida biz foydalanuvchi tomonidan review yoki shunga o`xshash mahsulotni sotib olishi uchun kerak bo`ladigan narsalarga qayta so`rov yuborishini oldini olyabmiz.
Foydalari :
- Ko`p yangi requestlarni oldini olish
- Cachelash oson
Undan keyin siz elektron magazin uchun mobila app qilishni ham xohladingiz (foydalanuvchilarga qulaylik uchun) .Endi sizning monolit serveringiz ham web ham mobileni ma’lumotlar bilan ta’minlashi kerak. Ular bir xil API ishlatishadi va bir xil javoblar olishadi .
Note : Mobil telefonlarda chegaralangan ko`rsatish maydoni(screen) bor !!
Mobil telefonda u ma’lumotlar hammasi ham ko`rsatilmaydi . Masalan reviewlar uchun keyingi sahifa ochiladi va u ma’lumotlarni o`sha yerda yuklab olish mumkin.
Bundan savol kelib chiqadi biz nega mobile uchun keraksiz malumotlarni berib yuboriyapmiz ? Kamaytirsak(faqatgina keraklilarni berib yuborsak) nima bo`ladi :
- Har bir so`rov bandwith kamayadi (ishlatilinadigan internet trafigi)
- Serverdagi keraksiz xotira va process jarayonlaridan qutulamiz
- UI qismda tez ishga tushishi va xursand foydalanuvchi.
Agar bu shunchaki mobile bo`lmasachi ya’ni biror bir AI bilan boshqariladigan dastur yoki boshqa bizning kompaniya bilan hamkorlikdagi foydalauvchi bo`lsachi ? Ularga ba’zi xavfsizlik ma’lumotlarini olib tashlab berishimiz yoki qo`shimcha ma’lumotlar qo`shib berishimiz kerak bo`lishi mumkin .Buni qanday qilib oson amalga oshirishimiz mumkin ?
1-usul .APIga query paramatr berish orqali platform web mobile,shunga o`xshash ammo bu holatda biz kodga bir necha if elselar qo`shib uni qiyinlashtirib yuboramiz.
2-usul .Xuddi shu yerda bizga Backend for Frontend patterni yordamga keladi.
BFF nima ?
BFF oddiy qilib aytganda xuddi biz tepada aytgan frontend va backend o`rtasida turuvchi alohida layer . Masalan :
Siz bunda monolitni o`zgartirishingiz kerak emas monolit sizga hamma malumotni beradi ,filterlash jarayoni BFF da amalga oshadi.Bunda http so`rovi qanday bo`ladi ? Web client web BFF ga so`rov yuboradi ,web BFF esa monolitga va u databazaga va olib uni BFF ga qaytaradi ,BFF filterlab uni Webga moslab web clientga uzatadi.BFF qismda hech qanday logika (bussines logika) bo`lmaydi . BFF backenddan olgan ma’lumotlarni clientga moslab filterlab beradi .
Endi sizga faqatgina bitta API emas BFF bizni har bir client uchun o`z API lari bilan ta’minlaydi.
BFF quyidagilarni amalga oshiradi:
- Nimalar backenddan olinishi.
- Ular qanday olinishi (protocollar).
- Javobda nimalar uzatilishi.
Endi mobil BFF da keraksiz ma’lumotlarni o`chirib yuborishim va web BFF da qo`shimcha ma’lumotlar bilan birgalikda uzatishimiz mumkin.
BFF microservicelarda
BFF pattern microservicelarga ham mos tushadi. Agarda siz aniq bir bosh servicesiz (hamma servicelarni bog`lab turadigan ) microservice orqali frontend qurmoqchi bo`lsangiz bizda har xil usullar bor bu to`g`ridan to`g`ri o`sha servicelarga murojaat qilish.Bu usul kichik va murakkab bo`lmagan dasturlar uchun qulay hisoblanadi .Ammo bu holatda frontend dasturchi backend va uni API lari haqida ko`proq bilishi va ma’lumotni boshqa servicega uzatib yubormasligi kerak .Bu holatda backendda servicelar osonlikcha almashtirib bo`lmaydi va bu frontend dasturini qayta serverga yuklashga olib keladi. Buning yana bir tomoni bu microservicedan qaytib kelayotgan ma’lumotlar frontend xohlagandek filtirlanmagan yoki tuzilmagan bo`lishi mumkin.
Sizda tepadagi misolday ammo microserviceda ecommerce dastur bor va foydalanuvchi frontendda sotib olishga tayyor mahsulotlarni ko`rmoqchi bu holatda Cart servisdan mahsulot idlari qaytib keladi va Product servicega borib har bir mahsulot haqida ma’lumotlarni yig`adi va bundan so`ng UI chizishi mumkin bo`ladi . Misoldan ko`rinib turgandek frontend microservicedan kelgan ma’lumotlarni foydlanuvchiga ko`rsatishi uchun ,unda yana qo`shimcha logika qismi qo`shilmoqda .Va bu frontend qismi bir necha API larni faqatgina bitta oyna chiqarish uchun chaqirishiga va frontend qismini ancha murakkablashtiradi . Texnik tomondan olib qarasak bir malumotni ko`rsatish uchun bir necha API lar chaqirilishi performance tushib ketishiga olib keladi.
BFF microserviceda nima ?
BFF oddiy qilib aytganda xuddi biz tepada aytgan frontend va backend o`rtasida turuvchi alohida service .Bu holatda frontend bir necha API larga chiqmasdan BFF ga bitta API orqali chiqadi va BFF hamma ma’lumotlarni yig`ib frontend uchun kerakli strukturaga olib kelib beradi va frontendga qaytaradi .Buning yordami frontend faqatgina bitta servicega(BFF) ga murojaat qiladi va ma’lumotlarni qabul qiladi .Va biz har xil foydalanuvchilar uchun yani Web va mobil alohida BFF lar yaratishimiz mumkin . Va Frontend backend API o`zgarishlariga bo`g`lanib qolmaydi va xatolikka chidamliligi oshadi (resilience) .Bundan tashqari BFF orqali microservicelardan qaytadigan sensitive ma’lumotlarni saqlab qolib qolganlarini uzatish ham mumkin.
BFF foydalari :
- client talablariga moslashish osonligi .
- maxfiy ma’lumotlarni oshkor qilmaslik yoki saqlab qolish .
- bir necha clientlarga alohida bog`lanmagan holda xizmat ko`rsatish.
- clientga mos protocl va stack tanlash. Masalan BFF bu sizni infrastrukturanigizda va u sizdagi backend bilan xohlagan protoclda gaplashishi mumkin.
- Xavfsizlikni kuchayishi
- Umumiy backend va xohlaganingizcha moslashtirish mumkin bo`lgan BFF.
BFF zararlari :
- ko`proq requestlar va latency osishi performance tushishi (buni oldini olish uchun to`gri stack va protocllar tanlanishi zarur) .
- kod qaytarilishi . (BFF lar orasida bir xil kodlar va service chaqiruvlari takrorlanishi mumkin).
- yangi BFF layer bu yana boshqarish kerak bo`lgan yangi qism .(Dasturchilarga qo`shimcha bosh og`riq)
Qachon BFF ishlatish tavsiya etiladi ?
- Clientlar o`rtasidagi so`rovga javob kutilmalar juda farq qilsa .Bitta umumiy backend va bir necha BFF layer orqali buni hal qilish mumkin.
- Client komunikatsiya protocollari yoki formatlari har xil bo`lsa .Masalan XML va JSON uchun alohida BFF yoki grpcda va TCP va HTTPda .
- Microfrontend uchun microservice arxitekturada BFF har bir microfrontend uchun .
Note : BFF frontend jamoasi qismi hisoblanadi odatda .(Agarda Fullstack bo`lmasangiz :).
Xulosa
Ko`rib turganingizdek BFF bu client uchun backend ma’lumotlarini moslab beruvchi prezintatsiya qismi hisoblanadi . Ammo haqiqatda kerak bo`lmaguncha qilish tavsiya etilmaydi (hype uchun :) ).
Agarda maqola yoqqan bo`lsa chapak chaling (ko`p chalsayam bo`ladi 50 tagacha).
Yana shunday maqolalar o`qishni xohlasangiz medium da follow tugmasini bosib qo`ying.
Xato va kamchiliklar uchun uzr !!!
linkedin.com => Ulug’bek Habibov | LinkedIn
telegram channel => @habibov_ulugbek