BFF vs API Gateway: Perbedaan dan Kapan Menggunakannya

“BFF vs API Gateway” adalah salah satu perbandingan yang paling membingungkan dalam arsitektur layanan mikro (microservices). Kedua pola ini terlihat serupa pada diagram. Keduanya berada di depan layanan Anda. Keduanya menerima permintaan klien dan meneruskannya ke backend. Jadi, tim berasumsi bahwa keduanya adalah pilihan yang bersaing, memilih salah satu, dan akhirnya menjejali tanggung jawab yang salah ke dalamnya.

Keduanya bukanlah pesaing. Backend for Frontend (BFF) dan API gateway menyelesaikan masalah yang berbeda, dimiliki oleh tim yang berbeda, dan sangat sering berjalan bersama dalam sistem yang sama. BFF berada di belakang atau di samping gateway, bukan menggantikannya.

Panduan ini menarik garis dengan jelas. Anda akan mempelajari apa sebenarnya masing-masing pola, di mana keduanya tumpang tindih, kapan menggunakan salah satu atau keduanya, dan kesalahan yang timbul karena mengaburkan keduanya. Sepanjang panduan ini, kontrak API adalah hal yang konstan: apakah permintaan mengalir melalui gateway, BFF, atau keduanya, setiap lapisan mengekspos API yang masih harus Anda rancang, uji, mock, dan dokumentasikan.

Apa Itu API Gateway?

Sebuah API gateway adalah titik masuk terpusat yang berada di antara klien dan layanan backend Anda. Setiap permintaan masuk melalui gateway, yang menerapkan serangkaian perhatian lintas-fungsi (cross-cutting concerns) yang konsisten sebelum meneruskan panggilan.

Perhatian-perhatian tersebut sama untuk setiap klien dan setiap layanan:

• Routing: mencocokkan jalur masuk ke layanan upstream yang tepat.
• Autentikasi dan otorisasi: memvalidasi token, menolak pemanggil yang tidak sah.
• Pembatasan laju (Rate limiting) dan pencekikan (throttling): melindungi backend dari kelebihan beban dan penyalahgunaan.
• Observabilitas: mencatat permintaan, memancarkan metrik, melacak panggilan di seluruh layanan.
• Terminasi TLS, caching, dan transformasi permintaan: menangani mekanisme sekali, di satu tempat.

Ciri khas gateway adalah bersifat umum (general purpose) dan dimiliki secara terpusat. Tim platform atau infrastruktur menjalankannya, dan melayani semua klien secara setara. Tidak peduli apakah pemanggilnya adalah aplikasi seluler, SPA web, atau integrasi mitra; gateway menerapkan kebijakan yang sama untuk semua orang.

Hal ini menjadikan gateway sebagai rumah alami untuk aturan di seluruh organisasi. Jika Anda ingin setiap permintaan diautentikasi dengan cara yang sama, atau setiap API dibatasi lajunya secara konsisten, gateway akan menegakkannya tanpa setiap layanan harus mengimplementasikan ulang logikanya. Untuk melihat perbedaannya dari tooling platform yang lebih luas, lihat manajemen API vs API gateway.

Apa Itu Backend for Frontend (BFF)?

Backend for Frontend, yang diperkenalkan oleh Sam Newman, membalik orientasi. Alih-alih satu backend serbaguna yang melayani setiap klien, Anda membangun satu backend per pengalaman pengguna. Aplikasi web mendapatkan BFF web. Aplikasi seluler mendapatkan BFF seluler. Setiap BFF disesuaikan persis untuk satu frontend. Pola ini tumbuh dari pekerjaan layanan mikro (microservices), di mana satu backend bersama yang melayani banyak klien menjadi jenis hambatan yang sama seperti monolith.

Aturan praktis Newman adalah “satu pengalaman, satu BFF.” Frontend yang sangat berbeda mendapatkan BFF-nya sendiri; yang serupa (aplikasi iOS dan Android yang dikelola oleh tim yang sama) dapat berbagi satu.

Ciri khas di sini adalah kepemilikan dan bentuk. BFF “terikat erat dengan pengalaman pengguna tertentu, dan biasanya akan dikelola oleh tim yang sama dengan antarmuka pengguna,” menurut Newman. Tim frontend memiliki BFF-nya. Mereka mengembangkan klien dan backend-nya secara bersamaan, tanpa menunggu tim backend terpisah untuk menyetujui setiap perubahan.

Apa sebenarnya yang dilakukan BFF? Ia membentuk data untuk satu klien:

• Agregasi: layar seluler membutuhkan data dari lima layanan mikro. BFF seluler memanggil kelima layanan tersebut dan mengembalikan satu respons gabungan, sehingga ponsel melakukan satu perjalanan pulang-pergi (round trip) alih-alih lima.
• Pemangkasan dan pembentukan ulang (Trimming and reshaping): klien seluler hanya membutuhkan tiga bidang dari empat puluh. BFF menghilangkan sisanya untuk menghemat bandwidth.
• Pemformatan khusus klien: aplikasi desktop mengambil beberapa halaman sekaligus untuk tampilan yang kaya; aplikasi seluler mengambil satu halaman agar tetap ringan. Setiap BFF melayani pola kliennya.

BFF adalah semacam agregator API dengan kepribadian: ia menyusun panggilan downstream, tetapi selalu untuk melayani satu frontend tertentu daripada sebagai lapisan netral yang dibagikan.

Di Mana BFF dan API Gateway Tumpang Tindih

Kebingungan ini dapat dimaklumi karena kedua pola ini berbagi perilaku permukaan. Keduanya menyadap permintaan klien. Keduanya dapat merutekan ke backend. Keduanya dapat memanggil beberapa layanan dan menggabungkan hasilnya. Diagram salah satunya terlihat seperti kotak di antara klien dan layanan.

Tumpang tindihnya nyata tetapi dangkal. Perbedaannya terletak pada tujuan dan kepemilikan:

• API gateway melakukan agregasi dan routing secara generik, untuk semua klien, untuk memusatkan kebijakan.
• BFF melakukan agregasi dan routing secara spesifik, untuk satu frontend, untuk mengoptimalkan pengalaman klien tersebut.

Panduan Microsoft sendiri lugas tentang pekerjaan mana yang harus ditempatkan di mana. Fitur lintas-fungsi seperti pemantauan, otorisasi, dan pembatasan laju harus diabstraksikan dari BFF dan ditangani secara terpisah oleh pola gaya gateway. BFF seharusnya hanya menampung logika khusus klien. Tempatkan autentikasi dan pembatasan (throttling) di BFF dan Anda baru saja membangun kembali setengah dari gateway, dengan buruk, dan Anda harus melakukannya lagi di setiap BFF yang Anda tulis.

Jadi, batasan praktisnya adalah ini: jika suatu tanggung jawab sama untuk setiap klien, itu milik gateway. Jika berubah per frontend, itu milik BFF.

BFF dan API Gateway Bekerja Bersama

Dalam sistem layanan mikro yang nyata, Anda jarang memilih salah satu. Anda menjalankan keduanya, berlapis. Gateway berada di tepi. BFF berada di belakangnya.

Alur permintaan tipikal terlihat seperti ini:

1. Klien seluler mengirimkan permintaan dengan token autentikasinya.
2. **API gateway** memvalidasi token, memberlakukan batas laju, mencatat permintaan untuk observabilitas, lalu merutekannya ke BFF seluler.
3. **BFF seluler** memanggil layanan produk, layanan inventaris, dan layanan harga, menggabungkan hasilnya, memangkas payload sesuai kebutuhan layar seluler, dan mengembalikan satu respons.
4. Gateway mengalirkan respons kembali ke klien.

Arsitektur referensi Microsoft untuk pola ini melakukan hal itu: API management gateway menangani otorisasi, pemantauan, caching, dan routing, kemudian meneruskan ke layanan BFF khusus klien yang berjalan sebagai fungsi tanpa server (serverless functions), yang memanggil layanan mikro yang mendasarinya.

Setiap lapisan melakukan apa yang terbaik. Gateway memiliki kebijakan yang harus seragam. BFF memiliki bentuk yang harus spesifik. Tim frontend mengirimkan perubahan ke BFF-nya tanpa menyentuh konfigurasi gateway, dan tim platform memperketat batas laju tanpa harus melakukan redeploy BFF apa pun.

Hubungan pelapisan ini mirip dengan bagaimana gateway hidup berdampingan dengan infrastruktur lain daripada menggantikannya. Gateway bukanlah penyeimbang beban (load balancer) (API gateway vs load balancer) dan juga bukan service mesh (service mesh vs API gateway); masing-masing menangani lapisan yang berbeda dari jalur permintaan, dan BFF hanyalah satu lapisan berbeda lainnya. Ini adalah prinsip yang sama di balik konektivitas berbasis API (API-led connectivity): berikan setiap lapisan tugas yang jelas dan biarkan ia melakukan itu saja.

Tabel Keputusan: BFF vs API Gateway

Bacalah ini sebagai pertanyaan routing untuk tanggung jawab. Yang sama untuk semua orang masuk ke gateway. Yang berbeda per frontend masuk ke BFF. Ketika suatu tanggung jawab adalah keduanya (Anda menginginkan autentikasi pusat tetapi juga pembentukan payload per klien), itu adalah sinyal Anda untuk menjalankan kedua lapisan, bukan memilih satu sisi.

Kapan Menggunakan yang Mana

Gunakan API gateway ketika Anda memiliki beberapa layanan dan membutuhkan satu tempat yang konsisten untuk menerapkan autentikasi, pembatasan laju, dan routing. Hampir setiap sistem layanan mikro mendapat manfaat dari ini. Jika Anda memiliki lebih dari segelintir layanan yang diekspos ke klien, Anda menginginkan gateway sebelum hal lain.

Gunakan BFF ketika klien yang berbeda memiliki kebutuhan yang berbeda secara signifikan dari backend yang sama, dan API serbaguna yang dibagikan telah menjadi hambatan. Pemicu umum, berdasarkan panduan Microsoft:

• Backend bersama membutuhkan upaya besar untuk dikelola karena melayani frontend yang bersaing.
• Anda terus menyesuaikan backend serbaguna untuk mengakomodasi beberapa antarmuka.
• Seluler dan web memiliki kebutuhan data dan kinerja yang benar-benar berbeda.

Lewati BFF ketika semua antarmuka Anda membuat permintaan yang sama atau serupa, atau hanya satu antarmuka yang berkomunikasi dengan backend. BFF menambah satu langkah jaringan (network hop), lebih banyak layanan untuk di-deploy, dan kemungkinan beberapa duplikasi kode di antara BFF. Jika satu API bersama melayani setiap klien dengan baik, BFF adalah beban tambahan yang tidak Anda butuhkan. Microsoft mencatat bahwa lapisan GraphQL dengan resolver per frontend juga dapat menghilangkan kebutuhan akan BFF terpisah, karena klien meminta bidang yang persis mereka inginkan.

Gunakan keduanya ketika Anda menjalankan layanan mikro dalam skala besar: gateway untuk kebijakan seragam di tepi, BFF di belakangnya untuk pembentukan khusus klien. Ini adalah kondisi akhir yang umum, bukan yang eksotis.

Kesalahan Umum

• Menempatkan autentikasi dan pembatasan laju di BFF. Ini adalah kesalahan utama. Perhatian lintas-fungsi (cross-cutting concerns) termasuk dalam gateway. Duplikasikan hal tersebut di seluruh BFF dan Anda akan mengalami penyimpangan (drift): BFF seluler menerapkan satu kebijakan, BFF web menerapkan yang lain, dan postur keamanan Anda kini menjadi tidak konsisten secara tidak sengaja.
• Membiarkan BFF menjadi monolith kedua. Sebuah BFF dimaksudkan untuk kecil dan berfokus pada satu pengalaman. Ketika tim menumpuk logika bisnis bersama ke dalamnya, ia tumbuh menjadi backend serbaguna lagi dan Anda telah memperkenalkan kembali hambatan yang seharusnya dihilangkan oleh pola tersebut.
• Menggunakan gateway sebagai BFF. Beberapa tim menambahkan aturan transformasi permintaan per klien langsung dalam konfigurasi gateway untuk menghindari pembangunan BFF. Ini berfungsi pada skala kecil, tetapi gateway dimiliki secara terpusat, sehingga tim frontend sekarang mengajukan tiket ke tim platform untuk setiap penyesuaian khusus klien. Anda telah mengawinkan tim yang salah.
• Membangun BFF ketika hanya ada satu klien. Jika Anda memiliki satu aplikasi web dan tidak ada klien lain di masa mendatang, BFF terlalu dini. Kirimkan API bersama. Tambahkan BFF ketika klien kedua yang berbeda benar-benar tiba.
• Melupakan kontrak. Setiap BFF dan setiap rute gateway mengekspos API. Masing-masing membutuhkan kontrak yang terdefinisi, pengujian, dan dokumentasi, sama seperti API lainnya. Lewati ini dan lapisan BFF Anda yang "tipis" menjadi kotak hitam yang tidak terdokumentasi yang tidak dapat diintegrasikan oleh siapa pun di luar tim pemilik. Lihat apa itu kontrak API mengapa ini penting.

Di Mana Apidog Cocok

Apakah sebuah permintaan mengalir melalui API gateway, BFF, atau keduanya, setiap lapisan mengekspos kontrak API. Apidog adalah tempat Anda merancang, menguji, mock, dan mendokumentasikan kontrak-kontrak tersebut. Ia tidak membangun, meng-host, atau menggantikan gateway atau BFF; ia memberi Anda satu ruang kerja untuk permukaan API yang mereka ekspos.

Secara konkret:

• Desain: memodelkan respons teragregasi BFF atau endpoint yang dirutekan gateway secara schema-first di desainer visual, lalu membuat OpenAPI untuk tim frontend dan backend Anda agar dapat dibangun.
• Mock: membuat mock cerdas dari BFF sehingga tim seluler dapat mengembangkan layar mereka sebelum layanan downstream BFF ada. Ini adalah alur kerja API-first yang memungkinkan pekerjaan frontend dan backend secara paralel.
• Uji: membangun skenario pengujian otomatis yang mengenai endpoint yang dilindungi gateway persis seperti yang akan dilakukan klien nyata, memvalidasi autentikasi, kode status, dan bentuk payload yang teragregasi.
• Dokumentasikan: mempublikasikan dokumen interaktif untuk setiap rute BFF dan gateway sehingga setiap tim pengonsumsi mengetahui kontrak tanpa harus membaca implementasinya.

Pola yang Anda pilih adalah keputusan arsitektur. Kontrak yang diekspos setiap lapisan adalah konstan. Apidog menangani hal yang konstan, sehingga BFF dan gateway Anda tetap dirancang, diuji, di-mock, dan didokumentasikan tidak peduli bagaimana Anda menghubungkannya.

Coba Apidog gratis untuk merancang dan mock kontrak BFF dan gateway Anda sebelum Anda menulis sebaris kode backend.

tombol

FAQ

• Apakah BFF adalah jenis API gateway? Tidak. Keduanya tumpang tindih dalam hal keduanya dapat merutekan dan melakukan agregasi, tetapi BFF dimiliki oleh tim frontend dan disesuaikan untuk satu pengalaman klien, sementara API gateway dimiliki secara terpusat dan melayani semua klien secara seragam. BFF biasanya berada di belakang gateway.
• Bisakah saya menggunakan BFF tanpa API gateway? Ya, tetapi Anda biasanya tidak boleh melakukannya dalam skala besar. Tanpa gateway, setiap BFF harus mengimplementasikan ulang perhatian lintas-fungsi (cross-cutting concerns) seperti autentikasi dan pembatasan laju, yang menyebabkan inkonsistensi. Gateway memusatkan hal-hal tersebut sehingga setiap BFF hanya menangani pembentukan khusus klien.
• Berapa banyak BFF yang harus saya miliki? Ikuti aturan Sam Newman “satu pengalaman, satu BFF.” Bangun BFF terpisah untuk setiap frontend yang sangat berbeda. Klien yang serupa yang dikelola oleh tim yang sama, seperti aplikasi iOS dan Android, dapat berbagi satu BFF.
• Apakah BFF menggantikan API gateway saya? Tidak. Keduanya adalah lapisan pelengkap. Gateway memberlakukan kebijakan seragam di tepi; BFF membentuk data untuk klien tertentu di belakangnya. Sebagian besar sistem layanan mikro nyata menjalankan keduanya.
• Kapan saya tidak boleh membangun BFF? Lewati ini ketika semua klien membuat permintaan yang serupa, ketika hanya ada satu klien, atau ketika lapisan GraphQL dengan resolver per frontend sudah memungkinkan klien mengambil data persis yang mereka butuhkan.
• Di mana seharusnya autentikasi dan pembatasan laju ditempatkan, di BFF atau gateway? Di gateway. Ini adalah perhatian lintas-fungsi yang harus seragam di semua klien. Menempatkannya di BFF menduplikasi logika di setiap BFF dan mengundang penyimpangan kebijakan.