BFF vs API Gateway: Trade-off Skalabilitas, Biaya, dan Maintenance

BFF vs API Gateway adalah keputusan arsitektur yang sering muncul saat aplikasi web atau backend mulai bertambah kompleks. Jawaban singkatnya: BFF cocok ketika kebutuhan tiap client berbeda signifikan dan tim ingin mengoptimalkan pengalaman web, mobile, atau partner secara terpisah; API Gateway cocok ketika kebutuhan utama adalah pintu masuk terpusat untuk concern lintas layanan seperti autentikasi, routing, rate limiting, dan observabilitas dasar.

Masalahnya, banyak tim memilih salah satu pola terlalu cepat atau mencampur tanggung jawabnya sampai sulit dipelihara. Artikel ini membahas trade-off nyata: performa, kompleksitas operasional, coupling dengan client, ownership tim, biaya infrastruktur, deployment, observabilitas, dan sinyal kapan perlu migrasi.

Memahami peran BFF dan API Gateway

Apa itu API Gateway

API Gateway adalah lapisan masuk tunggal ke backend. Ia biasanya menangani hal-hal umum seperti:

• routing request ke service yang tepat,
• autentikasi atau validasi token,
• rate limiting,
• terminasi TLS,
• header transformation sederhana,
• logging dan metrics dasar.

Gateway idealnya tidak menjadi tempat logika bisnis yang kaya. Semakin banyak orkestrasi dan transformasi spesifik client dimasukkan ke gateway, semakin besar risiko bottleneck teknis dan organisasi.

Apa itu BFF

Backend for Frontend (BFF) adalah backend yang dibuat khusus untuk satu jenis frontend atau satu pengalaman client tertentu, misalnya:

• BFF untuk web,
• BFF untuk mobile,
• BFF untuk admin dashboard,
• BFF untuk partner portal.

BFF biasanya melakukan agregasi data dari beberapa service, menyederhanakan payload untuk client tertentu, dan mengenkapsulasi kebutuhan presentasi yang tidak cocok dimasukkan ke service domain.

Dengan kata lain:

• API Gateway berfokus pada concern yang umum dan lintas client.
• BFF berfokus pada kebutuhan spesifik client.

Kapan memilih BFF vs API Gateway

Skenario 1: Satu frontend, backend mulai tumbuh

Jika Anda hanya punya satu frontend web dan beberapa backend service mulai muncul, pola yang paling aman biasanya adalah:

• mulai dari API Gateway sederhana bila kebutuhan masih dominan routing dan keamanan, atau
• mulai dari satu BFF bila frontend membutuhkan agregasi data, komposisi response, dan optimasi endpoint yang jelas berbeda dari model domain backend.

Untuk satu frontend, membangun gateway dan BFF sekaligus sering berlebihan. Pilih satu lapisan yang paling menyelesaikan masalah terbesar saat ini.

Pilih BFF lebih dulu jika frontend sering meminta perubahan endpoint agar halaman tidak perlu memanggil banyak API kecil. Ini tanda bahwa client membutuhkan API yang disesuaikan dengan use case tampilan, bukan hanya akses mentah ke service.

Pilih API Gateway lebih dulu jika masalah utama adalah konsolidasi akses ke banyak service, kontrol autentikasi, atau standardisasi pintu masuk tanpa banyak kebutuhan transformasi response.

Skenario 2: Banyak frontend dengan kebutuhan mirip

Jika ada beberapa frontend tetapi kebutuhan datanya cukup seragam, API Gateway sering cukup sebagai lapisan depan. Misalnya web internal dan dashboard operasional sama-sama memakai resource yang serupa, dengan variasi kecil di client.

Dalam kondisi ini, menambah banyak BFF bisa menciptakan duplikasi logika yang tidak perlu. Gunakan gateway untuk concern umum, dan biarkan client atau service backend menangani variasi kecil secara terukur.

Skenario 3: Mobile + web dengan kebutuhan berbeda nyata

Ini adalah kasus paling umum untuk BFF. Mobile dan web biasanya berbeda dalam beberapa hal:

• ukuran payload yang diinginkan,
• urutan data untuk rendering,
• strategi caching dan pagination,
• toleransi terhadap round trip jaringan,
• kebutuhan offline atau retry,
• siklus rilis aplikasi.

Jika mobile membutuhkan endpoint ringkas dan stabil, sementara web butuh response lebih kaya dan cepat berubah, satu API generik sering menjadi kompromi buruk. BFF per client memungkinkan optimasi tanpa memaksa semua client mengikuti model yang sama.

Skenario 4: Tim kecil vs tim bertambah

Tim kecil biasanya perlu menjaga jumlah komponen sesedikit mungkin. Menambah BFF terpisah untuk setiap frontend sejak awal bisa menaikkan beban deployment, monitoring, CI/CD, dan incident response.

Tim yang mulai bertambah justru sering lebih diuntungkan oleh pemisahan ownership. Tim web bisa memiliki BFF web, tim mobile memiliki BFF mobile, sementara platform team atau backend core team mengelola gateway dan service lintas domain.

Intinya, struktur organisasi memengaruhi desain arsitektur. Jika ownership tidak jelas, baik gateway maupun BFF akan berubah menjadi lapisan “serba bisa” yang sulit dijaga.

Tabel perbandingan BFF vs API Gateway

Trade-off teknis yang paling penting

1. Skalabilitas performa dan hop jaringan

Baik BFF maupun API Gateway menambah satu hop jaringan. Itu sendiri tidak otomatis buruk. Yang lebih penting adalah apakah lapisan tersebut mengurangi total biaya request end-to-end.

BFF sering meningkatkan performa yang dirasakan pengguna karena:

• menggabungkan beberapa panggilan backend menjadi satu request dari client,
• menghilangkan over-fetching atau under-fetching,
• menyesuaikan payload untuk kondisi jaringan client.

Namun BFF juga bisa memperburuk performa jika:

• melakukan pemanggilan berantai yang tidak paralel,
• terlalu banyak transformasi data,
• menjadi lapisan sinkron untuk terlalu banyak service lambat.

API Gateway biasanya lebih aman secara performa bila dibatasi pada routing dan policy enforcement. Begitu gateway ikut melakukan orkestrasi bisnis, latensi dan konsumsi resource naik, sementara debugging menjadi lebih sulit.

Prinsip praktis: kalau logic lapisan depan membutuhkan pemahaman kuat tentang tampilan client, itu cenderung pekerjaan BFF. Kalau logic-nya generik dan berlaku untuk semua request, itu cenderung pekerjaan gateway.

2. Kompleksitas operasional

API Gateway mengurangi kompleksitas akses dari sisi client dan membantu standardisasi. Tetapi secara operasional, gateway yang terlalu sentral bisa menjadi titik kegagalan dan bottleneck perubahan.

BFF meningkatkan jumlah service yang harus dikelola: pipeline build, secret, autoscaling, alarm, dashboard, tracing, dan pengujian kontrak. Pada tim kecil, overhead ini nyata.

Karena itu, pertanyaan yang tepat bukan “mana lebih modern”, melainkan:

• berapa banyak variasi client yang benar-benar perlu diakomodasi,
• siapa yang akan mengelola lapisan ini setiap hari,
• berapa cepat kebutuhan API per client berubah.

3. Coupling dengan client

BFF sengaja terikat pada kebutuhan frontend tertentu. Itu bukan kelemahan selama coupling tersebut lokal dan terkontrol. Justru ini memudahkan evolusi UI tanpa memaksa service domain mengikuti detail presentasi.

Masalah muncul jika BFF mulai menyimpan logika bisnis inti yang seharusnya berada di domain service. Saat itu, perubahan di frontend diam-diam mulai mengubah perilaku bisnis backend, dan batas tanggung jawab kabur.

API Gateway biasanya lebih longgar coupling-nya terhadap client. Ini baik untuk reuse, tetapi kurang ideal bila kebutuhan tiap client berbeda jauh. Hasil akhirnya sering berupa endpoint “serba guna” yang sulit dipahami dan dipelihara.

4. Ownership tim

Ownership yang jelas sering lebih penting daripada pola arsitekturnya sendiri.

• Gateway cocok dimiliki platform team atau backend core team.
• BFF cocok dimiliki tim yang bertanggung jawab langsung atas pengalaman client tertentu.

Jika semua tim bebas mengubah gateway untuk kebutuhan masing-masing, gateway akan cepat dipenuhi exception, custom route, dan transformasi khusus. Sebaliknya, jika BFF dikelola tim yang tidak memahami kontrak frontend, BFF hanya menjadi proxy tambahan tanpa nilai nyata.

5. Biaya infrastruktur

Biaya tidak hanya berarti tagihan compute. Ada beberapa komponen biaya:

• jumlah service yang dijalankan,
• traffic antar-service,
• log dan trace yang dihasilkan,
• upaya on-call dan debugging,
• waktu pengembangan untuk menjaga kompatibilitas.

BFF menambah biaya per client karena ada service tambahan. API Gateway mengefisienkan pintu masuk, tetapi jika menjadi lokasi orkestrasi berat, kebutuhan resource gateway juga naik dan scaling-nya bisa lebih mahal daripada membagi beban ke BFF terpisah.

Biaya jangka panjang sering lebih dipengaruhi oleh kesalahan penempatan tanggung jawab daripada jumlah komponen semata.

6. Observabilitas dan debugging

Semakin banyak lapisan, semakin penting tracing terdistribusi, correlation ID, dan logging terstruktur. Tanpa itu, Anda hanya melihat request “lambat” tanpa tahu apakah masalah ada di gateway, BFF, service downstream, cache, atau database.

Minimal, setiap request sebaiknya membawa ID korelasi yang diteruskan antar lapisan.

Client Request
  -> API Gateway (x-request-id)
    -> BFF Web (x-request-id diteruskan)
      -> User Service
      -> Order Service
      -> Inventory Service

Debugging akan jauh lebih mudah bila semua log menggunakan request ID yang sama. Selain itu:

• ukur latensi per hop, bukan hanya total latensi,
• bedakan error dari upstream dan error internal,
• catat timeout, retry, dan circuit breaker event secara eksplisit.

Contoh aliran arsitektur yang sehat

Opsi A: API Gateway tipis + service domain

Cocok untuk satu frontend atau beberapa client dengan kebutuhan mirip.

Client -> API Gateway -> Service A
                     -> Service B
                     -> Service C

Kelebihan:

• lebih sederhana secara operasional,
• standarisasi auth dan routing lebih mudah,
• jumlah komponen lebih sedikit.

Keterbatasan:

• client mungkin harus melakukan banyak request,
• optimasi spesifik mobile/web sulit dilakukan tanpa menambah kompleksitas di gateway atau service.

Opsi B: API Gateway tipis + BFF per client

Cocok untuk web dan mobile dengan kebutuhan berbeda atau saat organisasi mulai memisahkan ownership per channel.

Web Client    -> API Gateway -> BFF Web    -> Service A/B/C
Mobile Client -> API Gateway -> BFF Mobile -> Service A/B/C

Kelebihan:

• gateway tetap fokus pada concern umum,
• setiap client mendapat API yang sesuai kebutuhannya,
• ownership tim lebih jelas.

Keterbatasan:

• service bertambah,
• tracing dan deployment lebih kompleks,
• berpotensi ada duplikasi jika boundary tidak dijaga.

Contoh implementasi sederhana: kapan agregasi layak di BFF

Misalkan halaman dashboard web membutuhkan profil pengguna, 5 order terakhir, dan ringkasan notifikasi. Jika frontend harus memanggil tiga service sendiri, browser atau mobile app perlu menangani retry, timeout, dan komposisi data. Untuk use case seperti ini, BFF masuk akal.

async function getDashboard(req, res) {
  const userId = req.auth.userId;

  const [profile, orders, notifications] = await Promise.all([
    userService.getProfile(userId),
    orderService.getRecentOrders(userId),
    notificationService.getSummary(userId)
  ]);

  res.json({
    user: {
      id: profile.id,
      name: profile.name,
      tier: profile.tier
    },
    recentOrders: orders.items,
    unreadNotifications: notifications.unreadCount
  });
}

Contoh ini layak berada di BFF karena:

• response dirancang untuk satu layar tertentu,
• ada agregasi beberapa domain,
• format akhir lebih dekat ke kebutuhan UI daripada model domain murni.

Namun, jika BFF mulai memutuskan aturan diskon, validasi pembayaran, atau perubahan status order inti, itu sinyal logika bisnis mulai bocor keluar dari service domain.

Anti-pattern yang sering terjadi

1. Gateway menjadi monolit baru

Gejalanya:

• semua transformasi request/response diletakkan di gateway,
• gateway menyimpan banyak conditional logic per client,
• perubahan kecil di satu produk mewajibkan deploy gateway pusat.

Dampaknya: blast radius besar, bottleneck tim, dan debugging sulit. Gateway sebaiknya tetap tipis.

2. BFF hanya proxy tanpa nilai tambah

Jika BFF hanya meneruskan request 1:1 ke service tanpa agregasi, adaptasi payload, atau perlindungan terhadap kebutuhan client, Anda menambah hop dan biaya tanpa manfaat jelas.

3. Duplikasi logika domain di banyak BFF

Sering terjadi saat web dan mobile masing-masing menghitung aturan bisnis sendiri. Hasilnya tidak konsisten, sulit diuji, dan rawan bug lintas channel.

Aturan domain seharusnya tetap berada di service domain atau library bersama yang benar-benar terkontrol penggunaannya.

4. Kontrak API berubah mengikuti UI secara liar

BFF memang dekat dengan frontend, tetapi bukan berarti setiap perubahan kecil komponen UI harus langsung mengubah API. Jika tidak ada disiplin desain kontrak, BFF akan penuh endpoint sangat spesifik yang cepat usang.

5. Tidak ada strategi timeout dan fallback

BFF sering bergantung pada banyak upstream. Jika satu service lambat, seluruh halaman bisa ikut lambat. Terapkan:

• timeout per dependency,
• pemanggilan paralel saat memungkinkan,
• degradasi parsial untuk data non-kritis,
• cache untuk response yang aman di-cache.

Sinyal kapan migrasi atau refactor diperlukan

Dari API Gateway ke BFF

• Web dan mobile mulai membutuhkan payload yang sangat berbeda.
• Gateway mulai dipenuhi transformasi per client.
• Frontend sering meminta endpoint agregasi khusus layar tertentu.
• Release frontend terhambat karena perubahan backend generik terlalu lambat.
• Tim frontend membutuhkan ownership lebih langsung atas kontrak API mereka.

Dari BFF tunggal ke beberapa BFF

• Satu BFF melayani terlalu banyak channel dengan logika bercabang.
• Perubahan mobile berisiko merusak web, atau sebaliknya.
• Ownership tim sudah terpisah dan ritme rilis berbeda.
• Kebutuhan observabilitas dan scaling per channel mulai berbeda.

Dari banyak BFF ke konsolidasi sebagian

• Banyak endpoint dan transformasi ternyata duplikatif.
• Perbedaan antar-client mengecil seiring standardisasi produk.
• Biaya operasional service terpisah mulai tidak sebanding dengan manfaatnya.

Checklist keputusan: pilih yang mana?

Gunakan checklist berikut sebelum memutuskan.

1. Apakah client memiliki kebutuhan data yang benar-benar berbeda?
   Jika ya, condong ke BFF. Jika tidak, gateway tipis mungkin cukup.
2. Apakah masalah utama sekarang adalah concern umum atau kebutuhan UI spesifik?
   Concern umum: gateway. Kebutuhan UI spesifik: BFF.
3. Apakah tim Anda mampu mengelola service tambahan?
   Jika belum, hindari membuat banyak BFF terlalu dini.
4. Siapa owner dari kontrak API ini?
   Kalau owner-nya per frontend, BFF lebih natural. Kalau owner-nya platform bersama, gateway lebih cocok.
5. Apakah ada kebutuhan agregasi yang stabil dan berulang?
   Jika ya, BFF memberi nilai nyata.
6. Apakah gateway mulai berisi logika yang tidak generik?
   Jika ya, keluarkan ke BFF atau service yang lebih tepat.
7. Apakah service domain terpaksa menyesuaikan diri dengan format tampilan?
   Jika ya, BFF dapat melindungi domain dari coupling ke presentasi.
8. Apakah observabilitas sudah cukup matang?
   Jika belum ada tracing dan correlation ID, menambah lapisan baru akan memperumit debugging.

Rekomendasi praktis untuk aplikasi yang mulai tumbuh

Jika Anda masih punya satu frontend dan tim kecil

• Mulai dengan lapisan sesederhana mungkin.
• Pilih gateway tipis bila kebutuhan utama adalah routing, auth, dan standardisasi akses.
• Pilih satu BFF bila frontend sudah jelas membutuhkan agregasi dan kontrak API yang dekat ke UI.
• Jangan bangun BFF per halaman atau per fitur kecil.

Jika Anda punya web dan mobile

• Pertimbangkan gateway tipis di depan untuk concern umum.
• Buat BFF terpisah hanya jika kebutuhan payload, ritme rilis, dan optimasi benar-benar berbeda.
• Jaga agar aturan bisnis tetap di domain service.

Jika tim mulai bertambah

• Tentukan ownership yang eksplisit untuk gateway, BFF, dan service domain.
• Tetapkan batas tanggung jawab dalam dokumen arsitektur yang singkat tetapi operasional.
• Bangun tracing, dashboard latensi, dan error budget sebelum jumlah lapisan bertambah banyak.

Kesimpulan

Dalam perbandingan BFF vs API Gateway, tidak ada pemenang universal. API Gateway unggul sebagai pintu masuk terpusat untuk concern umum dan standardisasi akses. BFF unggul ketika kebutuhan tiap client berbeda nyata dan Anda ingin mengoptimalkan pengalaman web, mobile, atau channel tertentu tanpa mencemari service domain dengan kebutuhan presentasi.

Pilihan yang sehat biasanya bukan mengganti satu dengan yang lain secara total, tetapi menempatkan tanggung jawab di lapisan yang tepat. Untuk banyak sistem yang mulai tumbuh, kombinasi yang paling stabil adalah gateway yang tipis dan BFF hanya ketika memang dibutuhkan oleh variasi client atau ownership tim. Jika Anda disiplin menjaga boundary ini, skalabilitas, biaya, dan maintenance jangka panjang akan jauh lebih terkendali.