Apa itu Backend for Frontend (BFF)

Backend for Frontend (BFF) adalah layanan backend khusus yang dibangun untuk satu frontend spesifik. Alih-alih setiap klien (web, iOS, Android, pihak ketiga) berbicara dengan backend serbaguna yang sama, masing-masing mendapatkan lapisan sisi-servernya sendiri yang mengagregasi dan membentuk ulang data dari layanan mikro Anda menjadi muatan persis yang dibutuhkan antarmuka tersebut.

Sam Newman menamai dan mempopulerkan pola ini pada tahun 2015, berdasarkan pekerjaan yang dilakukan di SoundCloud. Lebih dari satu dekade kemudian, pola BFF masih menjadi alat standar bagi tim yang menjalankan layanan mikro di balik beberapa aplikasi klien, dan Microsoft mendokumentasikannya sebagai pola arsitektur cloud inti.

Masalah yang dipecahkan oleh BFF

Bayangkan sebuah sistem yang dimulai dengan satu aplikasi web dan satu backend. Backend mengekspos endpoint REST, aplikasi web mengonsumsinya, dan hidup terasa sederhana. Kemudian perusahaan meluncurkan aplikasi seluler. Lalu integrasi dengan mitra. Lalu widget jam tangan pintar. Tiba-tiba empat klien yang sangat berbeda semuanya menarik dari backend yang sama, dan backend itu mencoba menyenangkan semua orang sekaligus.

Ini menciptakan dua masalah berulang.

Over-fetching dan under-fetching. Sebuah endpoint serbaguna mengembalikan bentuk data yang tetap. Dasbor desktop mungkin menginginkan catatan pelanggan lengkap dengan riwayat pesanan, rekomendasi, dan pengaturan akun dalam satu respons. Aplikasi seluler pada koneksi seluler yang tidak stabil hanya menginginkan tiga bidang dan tidak lebih. Ketika keduanya memanggil endpoint yang sama, salah satunya mendapatkan jumlah data yang salah. Klien seluler entah mengunduh muatan yang membengkak yang harus dibuang (over-fetching) atau harus melakukan beberapa perjalanan pulang-pergi tambahan untuk mengumpulkan apa yang dibutuhkannya (under-fetching).

Klien yang cerewet (chatty clients). Ketika backend tidak disesuaikan dengan layar, klien mengkompensasinya dengan melakukan banyak panggilan. Layar beranda seluler yang membutuhkan data profil, jumlah notifikasi, dan feed mungkin memicu tiga atau empat permintaan terpisah ke tiga atau empat layanan mikro, kemudian menggabungkan hasilnya di perangkat. Setiap perjalanan pulang-pergi ekstra menyebabkan latensi dan menghabiskan baterai, dan logika orkestrasi bocor ke klien di mana sulit untuk diuji dan di-versi.

Ketegangan utamanya bersifat organisasional sama seperti teknis. Backend bersama memiliki tuntutan yang bersaing dari setiap tim frontend. Perubahan satu tim harus divalidasi terhadap kebutuhan setiap tim lain sebelum diluncurkan, yang mengubah backend menjadi hambatan dan sumber gesekan antar-tim.

Bagaimana pola BFF bekerja

Pola BFF memperkenalkan lapisan sisi-server tipis yang berada di antara satu frontend dan layanan hilir Anda. Setiap antarmuka mendapatkan backendnya sendiri.

[ Aplikasi Web ]    --->  [ Web BFF ]    ---\
[ Aplikasi iOS ]    --->  [ iOS BFF ]    -----> [ Layanan Mikro ]
[ Aplikasi Android] --->  [ Android BFF ] ---/

Setiap BFF melakukan tiga tugas untuk kliennya:

1. Agregasi. Ia memanggil layanan mikro hilir yang dibutuhkan layar dan menggabungkan responsnya, sehingga klien membuat satu permintaan alih-alih lima. Ini adalah agregasi API yang diterapkan pada satu pengalaman pengguna. Jika Anda menginginkan versi umum dari ide itu, lihat penjelasan kami tentang pola API aggregator.
2. Bentuk ulang. Ia memangkas bidang, mengganti nama menjadi istilah yang ramah klien, meratakan struktur berlapis, dan memformat nilai sesuai harapan antarmuka tersebut. BFF seluler mengembalikan muatan yang ramping; BFF desktop mengembalikan muatan yang kaya.
3. Terjemahkan. Ia menangani masalah spesifik klien seperti strategi paginasi, caching respons yang disesuaikan dengan klien tersebut, dan pilihan protokol, tanpa memaksakan keputusan tersebut pada layanan bersama di bawahnya.

Layanan mikro hilir tetap serbaguna dan agnostik terhadap frontend. Mereka mengekspos kemampuan yang bersih dan dapat digunakan kembali. BFF adalah tempat penyesuaian khusus klien berada, yang menjaga logika tersebut keluar dari layanan mikro maupun aplikasi klien. Jika Anda baru mengenal lapisan layanan di bawahnya, ikhtisar kami tentang layanan mikro versus API dan perpindahan dari monolit ke layanan mikro memberikan konteksnya.

Satu BFF per pengalaman klien

Panduan inti Newman singkat: satu pengalaman, satu BFF. Jika aplikasi iOS dan Android Anda menawarkan pengalaman yang berbeda secara signifikan, berikan masing-masing BFF-nya sendiri. Jika aplikasi web dan aplikasi seluler berbeda, aturan yang sama berlaku.

Inti dari aturan ini adalah menjaga setiap BFF tetap fokus. Saat satu BFF mencoba melayani dua klien dengan kebutuhan yang berbeda, ia mulai mengumpulkan logika kondisional ("jika seluler, kembalikan ini; jika web, kembalikan itu"), dan Anda kembali ke backend serbaguna dengan semua masalah koordinasi yang sama. BFF yang fokus tetap kecil, yang merupakan sifat yang membuat seluruh pola ini membuahkan hasil.

Ada pengecualian masuk akal yang Newman sendiri ambil dari SoundCloud: ketika satu tim memiliki dua klien yang serupa, seperti aplikasi iOS dan Android yang berbagi pengalaman yang hampir sama, masuk akal untuk berbagi satu BFF seluler di antara keduanya. Faktor penentu adalah kepemilikan dan kesamaan, bukan nama platform. Aturan ini adalah nilai baku, bukan hukum.

Kepemilikan milik tim frontend

BFF bukanlah lapisan yang dibangun dan diserahkan oleh tim platform. Tim frontend yang memiliki klien adalah pemilik BFF-nya. Ini adalah bagian kedua dari apa yang membuat pola ini berfungsi.

Ketika tim frontend memiliki BFF, mereka mengontrol irama rilisnya, memilih bahasa dan runtime-nya, memprioritaskan daftar tugasnya, dan mengirimkan perubahan ke klien dan layanan pendukungnya secara bersamaan. Perubahan UI yang membutuhkan endpoint teragregasi baru tidak memerlukan pengajuan tiket ke tim backend terpisah dan menunggu giliran di antrean tim tersebut. Tim yang merasakan masalah memiliki solusi.

Otonomi ini adalah kemenangan sejati. BFF menggeser batas sehingga keputusan khusus klien dibuat oleh orang-orang yang bertanggung jawab atas klien, yang persis seperti tempat pemikiran konektivitas berbasis API menempatkan tingkat "pengalaman".

BFF vs. API Gateway

Ini adalah perbandingan yang sering membuat kebanyakan tim keliru, karena BFF dan API gateway terlihat serupa dari sebuah diagram. Keduanya berada di antara klien dan layanan. Keduanya dapat merutekan dan mengagregasi. Namun, keduanya menjawab pertanyaan yang berbeda.

Sebuah API gateway adalah titik masuk serbaguna yang menangani masalah lintas-sektor untuk semua lalu lintas: otentikasi, pembatasan laju (rate limiting), perutean, penghentian TLS, dan pencatatan permintaan. Ini dimiliki oleh tim platform atau infrastruktur dan sengaja agnostik terhadap klien. Satu gateway melayani semua orang dengan cara yang sama.

BFF adalah kebalikannya. Ia dirancang khusus untuk klien, dimiliki oleh tim frontend, dan seluruh tujuannya adalah untuk berbeda untuk setiap antarmuka. Ini adalah tempat di mana pembentukan muatan klien tertentu berada, bukan titik kemacetan bersama.

Keduanya bukan saingan. Dalam tata letak produksi yang umum, API gateway berada di depan, menangani otentikasi, pembatasan laju, dan pemantauan untuk semua lalu lintas, lalu merutekan setiap klien ke BFF khusus di belakang gateway. Arsitektur referensi Microsoft menunjukkan persis seperti ini: sebuah gateway mengelola masalah lintas-sektor, dengan satu BFF tanpa server per klien di belakangnya. Gunakan gateway untuk apa yang sama di semua klien, dan BFF untuk apa yang berbeda. (Kami membahas versi mendalam dari kontras ini dalam artikel terpisah; di sini cukup untuk mengetahui bahwa mereka berada di lapisan yang berbeda dan menjawab kebutuhan yang berbeda.)

Untuk lanskap gateway di sekitarnya, perbandingan yang dipublikasikan ini membantu: API management vs. API gateway, API gateway vs. load balancer, dan service mesh vs. API gateway.

Kapan menggunakan BFF

Pola ini terbukti bermanfaat ketika kondisi berikut terpenuhi:

• Anda memiliki beberapa klien yang benar-benar berbeda. Web ditambah seluler ditambah integrasi mitra, masing-masing dengan kebutuhan data yang berbeda. Semakin banyak pengalaman yang menyimpang, semakin besar bantuan BFF.
• Backend bersama telah menjadi hambatan. Jika setiap perubahan frontend memaksa negosiasi antar-tim, memisahkan pembentukan spesifik klien menjadi BFF per tim akan menghilangkan biaya koordinasi.
• Anda menginginkan muatan yang dioptimalkan klien. Seluler membutuhkan respons yang ramping dan caching yang agresif; desktop menginginkan data teragregasi yang kaya. BFF memungkinkan Anda mengoptimalkan masing-masing tanpa kompromi.
• Bahasa yang lebih cocok untuk satu frontend. Sebuah tim dapat membangun BFF-nya dalam runtime yang sesuai dengan kliennya, terlepas dari apa yang digunakan BFF lain.

Kapan tidak menggunakan BFF

Pola ini tidak gratis, dan ada kasus jelas di mana ia menambah biaya tanpa imbalan:

• Anda hanya memiliki satu klien. Dengan satu antarmuka, BFF hanyalah lompatan ekstra. Bangun backend normal.
• Klien Anda membuat permintaan yang sama. Jika web dan seluler menginginkan data yang hampir identik dalam bentuk yang sama, BFF terpisah hanya menggandakan upaya tanpa manfaat. Konsolidasikan saja.
• GraphQL sudah memecahkan masalah pembentukan data Anda. Dengan GraphQL, setiap klien menanyakan bidang persis yang dibutuhkan dari satu endpoint, yang mencakup over-fetching dan under-fetching tanpa backend per klien. Jika Anda memiliki lapisan GraphQL dengan resolver khusus frontend, tingkat BFF terpisah seringkali tidak menambah nilai. Lihat apa itu GraphQL untuk menilai apakah itu cocok sebelum menambahkan tingkat BFF.
• Gateway ditambah layanan mikro sudah cukup. Untuk sistem yang lebih sederhana, API gateway di depan layanan mikro yang dirancang dengan baik dapat memberikan hasil yang dapat diterima tanpa lapisan khusus per klien.

Kerugian yang jujur

Bahkan ketika BFF adalah pilihan yang tepat, Anda menanggung biaya nyata. Memulainya dengan mata terbuka adalah bagian dari penggunaan pola ini dengan baik.

Duplikasi kode. Ini adalah pertukaran utama, dan dokumentasi Microsoft menyebutkannya secara langsung. Ketika tiga BFF semua perlu memanggil pemeriksaan otentikasi yang sama atau memformat tanggal yang sama dengan cara yang sama, logika itu cenderung ditulis tiga kali. Anda menukar duplikasi dengan penyesuaian. Solusinya adalah disiplin: simpan logika yang benar-benar dibagikan dalam pustaka yang diimpor oleh BFF, dan sisakan BFF itu sendiri untuk pembentukan khusus klien. Dorong masalah lintas-sektoral (otentikasi, pembatasan laju, pemantauan) ke gateway daripada mengimplementasikannya kembali per BFF.

Lebih banyak layanan untuk dioperasikan. Setiap BFF adalah unit yang dapat digunakan lainnya dengan siklus hidupnya sendiri, pipeline, rotasi siaga, dan permukaan keamanan. Lebih banyak layanan berarti lebih banyak overhead operasional.

Satu lompatan jaringan ekstra. Klien tidak lagi berbicara langsung ke layanan. BFF menambahkan satu lompatan, dan itu dapat menambah latensi. Ini biasanya pertukaran yang berharga karena BFF menghilangkan beberapa perjalanan pulang-pergi klien, tetapi ini adalah biaya yang harus diukur, bukan diasumsikan.

Risiko BFF menjadi bengkak. Jika BFF mulai melayani beberapa klien atau menyerap logika bisnis yang seharusnya berada di layanan mikro, ia akan kembali ke backend serbaguna yang Anda coba hindari. Jaga agar tetap ramping.

Menjaga kontrak BFF tetap sinkron dengan Apidog

Bagian sulit dalam menjalankan BFFs dalam praktik adalah kontrak. Setiap BFF mengekspos API yang menghadap kliennya sendiri, dan itu juga bergantung pada kontrak layanan mikro di bawahnya. Itu adalah banyak antarmuka yang bergerak di antara tim yang memiliki lapisan berbeda, dan penyimpangan di antara mereka adalah tempat asal bug dan klien yang rusak.

Di sinilah Apidog cocok dengan alur kerja. Apidog adalah platform desain, pengujian, mocking, dan dokumentasi API, sehingga kontrak API setiap BFF memiliki satu rumah tempat tim frontend dan backend dapat bekerja:

• Rancang kontrak terlebih dahulu. Definisikan setiap endpoint BFF serta skema permintaan dan responsnya di desainer visual Apidog dengan OpenAPI di bawahnya, sehingga bentuk yang menghadap klien disepakati sebelum kode ditulis. Ini adalah pendekatan kontrak-pertama yang diterapkan pada lapisan BFF, dan ini menjaga kontrak API tetap eksplisit.
• Lakukan mock sebelum ada. Tim frontend dapat mulai membangun berdasarkan mock pintar Apidog dari BFF pada hari kontrak disepakati, tanpa menunggu BFF atau layanan hilirnya siap.
• Uji kontraknya. Uji otomatis dan pernyataan Apidog memverifikasi bahwa setiap BFF mengembalikan muatan yang teragregasi dan dibentuk ulang sesuai harapan kliennya, dan mereka sesuai dengan CI sehingga perubahan hilir yang merusak respons BFF terdeteksi lebih awal.
• Dokumentasikan untuk kedua belah pihak. Apidog secara otomatis menghasilkan dokumen interaktif dari kontrak, sehingga tim frontend yang membaca API BFF dan tim backend yang memiliki layanan di bawahnya berbagi satu sumber kebenaran.

Untuk memperjelas ruang lingkup: Apidog tidak membangun, menghosting, atau menjalankan BFF Anda, dan itu bukan API gateway. Ini adalah tempat Anda merancang, melakukan mock, menguji, dan mendokumentasikan kontrak API yang menjadi dasar setiap BFF, yang menjaga tim frontend dan backend tetap sinkron saat BFF berkembang. Memperlakukan setiap BFF sebagai produk dengan kontrak yang stabil dan terdokumentasi dengan baik adalah yang membuat pola ini berkelanjutan.

FAQ

• Apakah BFF itu layanan mikro? BFF adalah layanan sisi server, dan dalam pengaturan layanan mikro, biasanya berjalan sebagai salah satunya. Namun, tugasnya berbeda dari layanan mikro tipikal. Layanan mikro memiliki kemampuan bisnis dan tetap agnostik terhadap klien; BFF memiliki pengalaman satu klien dan ada untuk mengagregasi serta membentuk ulang layanan mikro tersebut untuk klien tersebut. Ini adalah layanan lapisan pengalaman, bukan layanan kemampuan bisnis.
• Berapa banyak BFF yang harus saya miliki? Defaultnya adalah satu per pengalaman klien yang berbeda: satu untuk web, satu untuk iOS, satu untuk Android, dan seterusnya. Gabungkan dua hanya ketika satu tim memiliki klien dengan kebutuhan yang hampir identik. Pisahkan lebih lanjut ketika satu BFF mulai mengumpulkan logika kondisional per klien.
• Apakah GraphQL menggantikan pola BFF? Bisa, untuk bagian pembentukan muatan. GraphQL memungkinkan setiap klien meminta bidang persis yang dibutuhkan dari satu endpoint, yang mencakup over-fetching dan under-fetching tanpa backend per klien. Jika Anda memiliki GraphQL dengan resolver khusus frontend, tingkat BFF terpisah seringkali tidak menambah nilai. BFF tetap membantu ketika Anda membutuhkan orkestrasi per klien, terjemahan protokol, atau pilihan runtime yang tidak dapat dengan mudah disediakan oleh server GraphQL bersama.
• Bisakah saya menggunakan BFF dan API gateway bersama? Ya, dan itu umum. API gateway menangani masalah yang dibagikan di semua klien, seperti otentikasi, pembatasan laju, dan pemantauan, dan merutekan lalu lintas ke BFF yang tepat. Setiap BFF menangani apa yang spesifik untuk kliennya. Mereka berada di lapisan yang berbeda dan melakukan pekerjaan yang berbeda.
• Siapa yang harus memiliki BFF? Tim frontend yang memiliki klien. Kepemilikan itu adalah inti dari pola ini. Ini memungkinkan tim untuk mengirimkan perubahan UI dan endpoint pendukung secara bersamaan, memilih runtime-nya sendiri, dan bergerak tanpa menunggu antrean tim backend terpisah.
• Apakah BFF menambah latensi? Ini menambah satu lompatan jaringan, yang memiliki biaya. Dalam praktiknya, biasanya mengurangi total latensi klien, karena ia menggantikan beberapa perjalanan pulang-pergi klien-ke-layanan dengan satu permintaan klien-ke-BFF dan memungkinkan BFF memanggil layanan secara paralel di dekatnya. Ukur untuk beban kerja Anda daripada mengasumsikan salah satu caranya.