Backend for Frontend Architecture

Bayangkan tim kamu sedang membangun aplikasi e-commerce. Ada website yang diakses lewat laptop, aplikasi mobile untuk Android dan iOS, dan aplikasi khusus untuk kasir di toko fisik. Semua channel ini memanggil API yang sama—satu backend monolit yang melayani semua kebutuhan.

Awalnya berjalan mulus. Tapi semakin hari, keluhan mulai muncul. Tim mobile mengeluh karena API mengembalikan data yang terlalu banyak—mereka hanya butuh nama produk dan harga, tapi dapat deskripsi panjang, rating, stok di 10 gudang, dan ulasan yang tidak dipakai di layar kecil. Tim web protes karena harus melakukan tiga kali panggilan API terpisah untuk satu halaman detail produk. Tim kasir bingung karena endpoint yang sama kadang timeout di jaringan toko yang lambat.

Backend yang satu itu tidak bisa memuaskan semua orang. Setiap channel punya kebutuhan data, performa, dan pola interaksi yang berbeda. Solusi yang membuat web cepat justru membuat mobile boros bandwidth. API yang efisien untuk mobile ternyata tidak cukup fleksibel untuk web. Inilah masalah nyata yang membuat pola Backend for Frontend lahir.

Masalah yang Diselesaikan

Inti masalahnya sederhana: satu backend umum tidak bisa optimal untuk semua frontend. Ketika tim backend mencoba membuat API yang cocok untuk semua, hasilnya biasanya kompromi yang tidak memuaskan siapa pun. Frontend kelebihan data (over-fetching) atau kekurangan data (under-fetching), dan harus melakukan banyak round trip untuk mengumpulkan informasi yang sebenarnya bisa digabung.

Dampaknya langsung terasa di pengalaman pengguna. Aplikasi mobile jadi lambat karena harus mengunduh data yang tidak terpakai. Halaman web perlu menampilkan spinner berkali-kali karena data harus dikumpulkan dari beberapa endpoint. Tim frontend juga terbebani: mereka harus menulis logika orkestrasi data di sisi klien, yang berarti duplikasi kode di setiap channel dan kesulitan saat API berubah.

Komponen Utama

Pola BFF membagi arsitektur menjadi tiga lapisan yang jelas. Pertama, Frontend Channels—ini adalah klien spesifik yang berinteraksi langsung dengan pengguna. Ada Web App untuk browser, Mobile App untuk perangkat genggam, Desktop App untuk aplikasi native di komputer, dan Smart TV App untuk layar televisi. Masing-masing punya keterbatasan dan kelebihan sendiri: ukuran layar, bandwidth jaringan, kemampuan pemrosesan, dan pola interaksi yang berbeda.

Kedua, BFF Layer—inilah inti dari pola ini. Setiap frontend channel mendapat backend khusus yang dirancang untuk kebutuhannya. Ada Web BFF, Mobile BFF, Desktop BFF, dan TV BFF. Masing-masing BFF bertanggung jawab untuk data shaping, API aggregation, authentication, dan caching sesuai kebutuhan channel-nya. Web BFF mungkin mengembalikan data yang lebih kaya dengan relasi yang sudah digabung, sementara Mobile BFF mengutamakan payload yang ringan dan respons cepat.

Ketiga, Shared Backend Services—lapisan paling bawah berisi layanan bisnis umum seperti User Service, Product Service, Order Service, dan Notification Service. Layanan-layanan ini tetap generik dan bisa dipakai ulang oleh semua BFF. Mereka tidak perlu tahu channel mana yang mengonsumsi datanya.

Alur Kerja

Alur data dalam arsitektur BFF mengalir satu arah: Frontend Channels mengirim request ke BFF Layer yang sesuai dengan channel-nya, lalu BFF memproses request tersebut dengan mengambil data dari Shared Backend Services. Web App hanya bicara ke Web BFF, Mobile App hanya ke Mobile BFF, dan seterusnya.

Setiap BFF bertindak seperti penerjemah dan pengatur. Misalnya, ketika Mobile App meminta detail produk, Mobile BFF akan memanggil Product Service untuk data produk, User Service untuk rating, dan mungkin Order Service untuk stok. Data dari ketiga layanan itu digabung, dipotong sesuai kebutuhan mobile, lalu dikembalikan dalam satu respons yang ringkas. Frontend tidak perlu melakukan tiga kali panggilan atau menyaring data yang tidak dipakai.

Kapan Pola Ini Cocok Dipakai

BFF paling berguna ketika kamu punya produk multi-channel dengan kebutuhan frontend yang benar-benar berbeda. E-commerce dengan web, mobile, dan kiosk di toko adalah contoh klasik. Platform media streaming yang harus berjalan di smartphone, tablet, smart TV, dan laptop juga sangat cocok. Aplikasi perbankan yang punya versi untuk nasabah ritel dan versi berbeda untuk nasabah bisnis juga bisa diuntungkan.

Pola ini juga cocok ketika tim frontend ingin punya otonomi lebih. Dengan BFF, tim mobile bisa mengubah API mereka tanpa harus menunggu tim web setuju. Setiap BFF bisa di-deploy secara independen, sehingga perubahan untuk satu channel tidak mengganggu channel lain.

Trade-off, Batasan, dan Risiko Operasional

BFF bukan tanpa harga. Kamu harus siap mengelola lebih banyak service. Daripada satu backend, sekarang ada empat atau lima BFF yang masing-masing perlu di-maintain, di-deploy, dan dimonitor. Ini berarti lebih banyak kode yang harus ditulis, lebih banyak pipeline CI/CD, dan lebih banyak endpoint yang perlu diawasi.

Risiko terbesar adalah duplikasi logika. Jika tidak dikelola dengan baik, setiap BFF bisa mengimplementasikan ulang fungsi yang sama—misalnya caching strategy atau format response—dengan cara yang berbeda-beda. Ini tidak hanya boros, tapi juga bisa menyebabkan inkonsistensi data antar channel. Diperlukan governance API yang kuat dan kebiasaan berbagi kode lintas BFF.

Operasional juga jadi lebih kompleks. Setiap BFF perlu di-scale secara independen berdasarkan traffic channel-nya. Web BFF mungkin perlu 10 instance sementara TV BFF cukup dengan 2. Monitoring harus dilakukan per endpoint BFF, bukan hanya di level agregat. Tim operasional perlu dashboard yang bisa menunjukkan kesehatan masing-masing BFF secara terpisah.

Implikasi Praktis untuk Tim Engineering

Keputusan pertama yang harus diambil adalah siapa yang memiliki BFF. Praktik terbaik menyarankan setiap BFF dimiliki oleh tim frontend yang bersangkutan. Tim mobile mengelola Mobile BFF, tim web mengelola Web BFF. Ini membuat tim frontend punya kendali penuh atas API yang mereka konsumsi dan bisa bergerak lebih cepat.

Kedua, pilih protokol API yang sesuai per channel. Web BFF mungkin cocok dengan REST, sementara Mobile BFF bisa memakai GraphQL untuk fleksibilitas query. TV BFF mungkin lebih cocok dengan protokol yang ringan karena keterbatasan perangkat. Tidak ada keharusan semua BFF memakai protokol yang sama.

Ketiga, siapkan infrastruktur untuk deployment terpisah. Setiap BFF harus punya pipeline CI/CD sendiri, bisa di-deploy secara independen, dan punya strategi canary deployment per channel. Ini memungkinkan kamu menguji perubahan di Web BFF dengan lalu lintas terbatas sebelum merilis ke semua pengguna web, tanpa mempengaruhi channel lain.

Keempat, investasi di monitoring dan observability sejak awal. Karena jumlah service bertambah, kamu perlu tahu BFF mana yang lambat, endpoint mana yang error, dan channel mana yang terganggu. Tanpa visibilitas yang baik, BFF justru bisa menjadi sumber masalah baru yang sulit dilacak.

Terakhir, jangan tergoda menerapkan BFF untuk aplikasi sederhana dengan satu frontend. Pola ini menambah kompleksitas yang tidak perlu jika kamu hanya punya web app dan tidak ada rencana untuk channel lain. Mulailah dengan backend umum yang baik, dan baru pikirkan BFF ketika kebutuhan multi-channel benar-benar terasa.