API gateway vs BFF untuk klien web dan mobile: pertimbangan

Masalah: satu backend, banyak klien, kebutuhan yang berubah

Awal yang sering dipilih itu sederhana: satu backend membuka beberapa endpoint, dan baik aplikasi web maupun mobile memanggilnya. Terlihat efisien karena ada satu tempat untuk menambah fitur, memperbaiki bug, dan menegakkan aturan.

Lalu kenyataan muncul. UI web sering butuh layar padat, filter, ekspor, dan aksi admin. Mobile biasanya butuh lebih sedikit field, layar yang lebih cepat, alur yang ramah offline, serta hemat baterai dan data. Bahkan ketika fiturnya "sama", bentuk API terbaik untuk tiap klien jarang identik.

Seiring waktu, endpoint melenceng. Tim web menambah field untuk tampilan tabel baru. Mobile minta menghapus payload berat dan menggabungkan beberapa panggilan jadi satu. Seseorang menambahkan parameter "khusus iOS". Orang lain memakai endpoint admin internal di aplikasi publik karena "sudah ada". Yang dimulai sebagai satu API bersih jadi kumpulan kompromi.

Risikonya muncul cepat:

• Perubahan yang memecah saat satu klien rilis lebih cepat dari yang lain
• Aplikasi menjadi lambat karena payload besar atau terlalu banyak ronde panggilan
• Kode backend makin rumit karena setiap endpoint mencoba melayani semua klien
• Kebocoran data tidak sengaja ketika field atau aksi internal ikut terekspos ke API publik
• Versiasi menyakitkan karena "perubahan kecil" tidak kecil untuk klien lama

Itu adalah ketegangan inti di balik diskusi API gateway vs BFF. Anda ingin API publik yang stabil yang bisa diandalkan mobile dan web, sambil memberi setiap klien ruang berkembang dengan caranya sendiri.

API gateway dan BFF: apa itu (dan bukan itu)

API gateway adalah pintu masuk untuk API Anda. Klien memanggil gateway, dan gateway merutekan permintaan ke layanan backend yang tepat. Biasanya ia menangani concern bersama yang tidak ingin Anda ulang di banyak tempat, seperti pemeriksaan autentikasi, rate limit, logging request, dan shaping request dasar.

Backend-for-frontend (BFF) adalah backend kecil yang dibangun untuk satu klien atau grup klien spesifik, seperti "web" dan "mobile". Klien memanggil BFF-nya, dan BFF memanggil layanan di bawahnya. Ide utamanya adalah fokus: BFF boleh berbicara dalam "bahasa" klien (layar, alur, payload), meski layanan inti tetap lebih generik.

Yang bukan tugas pola ini: mereka bukan pengganti layanan domain yang baik atau model data yang bersih. Layanan inti, database, dan aturan bisnis Anda harus tetap sumber kebenaran. Gateway atau BFF tidak boleh berubah jadi gumpalan besar aturan bisnis yang lambat laun menjadi backend asli Anda.

Cara sederhana membedakannya:

• Gateway: satu titik masuk, concern bersama, routing dan proteksi
• BFF: API spesifik-klien yang mengurangi kerja klien dan menyembunyikan kompleksitas internal

Keduanya bisa dikombinasikan. Setup umum adalah gateway sebagai edge publik, lalu BFF terpisah di belakangnya untuk web dan mobile. Gateway menangani keamanan luar dan aturan lalu lintas, sedangkan tiap BFF membentuk endpoint dan respons untuk kliennya.

Bagaimana jalur request berubah di tiap pola

Perbedaan terbesar antara API gateway dan BFF adalah di mana Anda meletakkan logika "pintu depan": routing, pengecekan autentikasi, dan shaping respons.

Dengan API gateway, klien biasanya berbicara ke satu titik masuk bersama. Gateway meneruskan permintaan ke layanan internal, sering melakukan tugas dasar seperti validasi token, rate limit, dan routing berdasarkan path.

Dengan BFF, tiap tipe klien (web, iOS, Android) memanggil backend yang dibuat khusus untuknya. BFF itu lalu memanggil layanan internal dan mengembalikan respons yang disesuaikan dengan layar dan keterbatasan klien itu.

Gambaran jalur permintaan yang sederhana:

• Jalur API gateway: Klien -> Gateway -> Layanan -> Respons
• Jalur BFF: Klien -> BFF (web atau mobile) -> Layanan -> Respons

Kepemilikan juga sering bergeser. Tim platform atau infrastruktur biasanya memiliki gateway karena berdampak ke semua tim dan layanan. Tim fitur sering memiliki BFF karena bergerak seiring UI dan siklus rilisnya.

Autentikasi umum mengalir seperti ini: klien mengirim token, lapisan edge (gateway atau BFF) memvalidasinya atau meneruskannya ke layanan auth, lalu meneruskan detail identitas (user id, role) ke layanan downstream. Bedanya adalah di mana aturan klien diterapkan. Dengan gateway, kebijakan biasanya generik dan konsisten lintas klien. Dengan BFF, Anda bisa menambah shaping spesifik-klien, misalnya mengembalikan payload lebih kecil untuk mobile atau menggabungkan beberapa panggilan layanan jadi satu respons di jaringan lambat.

Langkah shaping inilah keunggulan BFF, tapi juga berarti lebih banyak bagian yang harus dideploy dan dijaga konsistensinya.

Memisahkan endpoint publik vs internal dengan aman

Endpoint publik adalah rute API yang bisa dijangkau oleh aplikasi web Anda, aplikasi mobile, mitra, atau pihak ketiga. Perlakukan sebagai lingkungan berbahaya secara default, karena Anda tidak dapat mengontrol jaringan yang dilalui atau kode klien yang memanggilnya.

Endpoint internal dimaksudkan untuk trafik antar-layanan di dalam sistem Anda. Ia bisa berubah lebih cepat, mengasumsikan konteks lebih banyak, dan mengekspos data lebih kaya, tapi tidak boleh dapat diakses langsung dari internet publik.

Dengan API gateway, pemisahan sering bersifat fisik dan mudah dipahami: hanya gateway yang terekspos, dan gateway memutuskan rute eksternal mana yang ada. Segala sesuatu di belakangnya tetap privat. Anda bisa menjaga API layanan internal ekspresif, sementara gateway menegakkan permukaan yang lebih kecil dan aman.

Dengan pola backend-for-frontend, pemisahan lebih tentang batas produk. Setiap klien (web, iOS, Android) hanya berbicara ke BFF-nya, dan BFF memanggil layanan internal. Itu memungkinkan Anda menyembunyikan kompleksitas internal: BFF bisa memanggil tiga layanan, menggabungkan hasil, dan mengekspos satu respons sederhana yang cocok dengan kebutuhan klien.

Pemisahan hanya aman jika Anda menambahkan kontrol praktis:

• Autorisasi spesifik: role dan scope per-rute, bukan satu tombol "sudah login"
• Rate limit per pengguna, token, dan IP untuk endpoint publik
• Penyaringan payload: kembalikan hanya yang klien butuh, buang ID internal, info debug, dan field khusus admin
• Allowlist jelas: endpoint mana publik, mana internal-only

Contoh: aplikasi mobile butuh layar "My Orders". BFF bisa mengekspos /orders hanya dengan status pesanan dan total, sementara layanan order internal menyimpan rincian biaya dan flag fraud yang tetap privat.

Versiasi: apa yang menjadi lebih mudah dan apa yang menjadi lebih sulit

Rasa sakit versi biasanya muncul ketika web dan mobile bergerak dengan kecepatan berbeda. Tim web bisa rilis dan rollback dalam jam. Aplikasi mobile butuh berhari-hari atau berminggu karena review app store dan pengguna yang tak segera memperbarui. Kesenjangan itulah yang membuat keputusan API gateway vs BFF bersifat praktis.

Dengan API gateway, Anda bisa meletakkan versi di satu pintu depan (mis. /v1/..., /v2/...). Ini mudah dijelaskan dan dirutekan. Kekurangannya, gateway bisa berubah jadi museum versi jika banyak klien dan integrasi mitra bertahan pada versi lama. Anda jadi harus mendukung bentuk data lama lebih lama.

Dengan BFF, versi sering "per klien". BFF mobile bisa tetap pada kontrak lama sementara BFF web bergerak lebih cepat, meski keduanya memanggil layanan internal yang sama. Itu biasanya mengurangi tekanan untuk mempertahankan versi publik selamanya. Tradeoff-nya adalah lebih banyak bagian yang harus dikelola: kini Anda punya beberapa keputusan versi untuk diatur dan dideploy.

Versiasi di dalam layanan juga mungkin, tapi itu mendorong perubahan yang dipicu klien lebih dalam ke sistem Anda. Hal itu juga bisa membuat kode internal lebih sulit dibaca karena logika layanan mulai bercabang berdasarkan versi klien.

Perubahan non-breaking adalah sahabat terbaik: menambahkan field opsional, menambah endpoint baru, atau menerima field input ekstra. Perubahan yang memecah meliputi mengganti nama field, mengubah tipe (string ke number), atau menghapus endpoint.

Deprecation paling baik bila direncanakan:

• Tetapkan tanggal sunset yang jelas dan komunikasikan sejak awal
• Lacak penggunaan versi lama (logs, metrik) dan awasi pengguna yang tertinggal
• Luncurkan pembaruan klien lebih dulu (khususnya mobile), lalu hapus jalur lama
• Kembalikan pesan error yang jelas ketika versi lama akhirnya diblokir

Performa: latency, ukuran payload, dan jumlah panggilan

Performa dalam setup API gateway vs BFF pada dasarnya adalah trade-off: satu hop ekstra di dalam sistem Anda versus lebih sedikit hop di jaringan klien. Pilihan tercepat seringkali yang mengurangi waktu jaringan klien yang lambat atau tidak dapat diandalkan, meski menambah sedikit langkah di server.

BFF sering menang ketika klien akan membuat banyak panggilan. Alih-alih web dan mobile memanggil lima endpoint dan menyatukan hasil di perangkat, BFF bisa mengambil yang dibutuhkan di server dan mengembalikan satu respons. Itu biasanya memangkas latency total di mobile karena jaringan seluler menambah delay tiap permintaan.

Keuntungan performa umum dari gateway atau BFF:

• Agregasi: gabungkan data dari beberapa layanan jadi satu respons
• Caching lebih cerdas: cache di edge atau di BFF untuk layar yang banyak baca
• Payload lebih kecil: kembalikan hanya field yang layar butuh
• Lebih sedikit round trip: kurangi perilaku chattiness di klien
• Kompresi dan timeout konsisten: tegakkan default di satu tempat

Tapi pola ini juga bisa merugikan. Setiap lapisan tambahan menambah kerja CPU dan lebih banyak tempat untuk menunggu. Jika Anda menggandakan logika agregasi untuk web dan mobile, Anda mungkin menggandakan kerja dan menciptakan perilaku yang tidak konsisten. Over-fetching juga sering terjadi: endpoint generik yang mencoba memenuhi semua layar dapat mengembalikan payload besar yang membuang-buang waktu dan bandwidth.

Kondisi mobile membuat trade-off ini lebih tajam. Jaringan yang fluktuatif membuat retry dan timeout normal, dan setiap panggilan tambahan menguras baterai. Cold start juga penting: jika aplikasi butuh beberapa permintaan sebelum layar pertama bisa dipakai, pengguna akan merasakannya.

Aturan praktis: optimalkan untuk lebih sedikit permintaan klien dulu, lalu optimalkan hop tambahan itu.

Cara cepat menilai desain

Jika sebuah layar butuh lebih dari 2–3 panggilan berurutan, pertimbangkan agregasi. Jika respons besar dan sebagian besar tidak terpakai, pertimbangkan memecah endpoint atau menggunakan BFF yang disesuaikan per klien.

Operasi: deployment, monitoring, dan scaling

Dengan API gateway vs BFF, pertanyaan operasional besar adalah berapa banyak bagian bergerak yang bersedia Anda jalankan dan dukung. Gateway sering menjadi infrastruktur bersama untuk banyak tim dan klien. BFF biasanya layanan kecil, tapi Anda mungkin punya satu per klien (web, iOS, Android, partner), yang menambah beban rilis dan on-call.

Pada testing dan rilis, gateway bisa lebih aman ketika kebutuhan Anda terutama routing, auth, dan rate limit. Perubahan terpusat, jadi satu kesalahan bisa memengaruhi semua orang. BFF mengurangi blast radius karena perubahan khusus web cukup dideploy ke web BFF, bukan ke mobile. Tradeoff-nya adalah lebih banyak pipeline yang harus dipelihara dan lebih banyak versi yang berjalan bersamaan.

Untuk observability, Anda perlu melihat satu permintaan pengguna melintasi lapisan, terutama saat satu panggilan mobile memicu beberapa panggilan backend.

• Gunakan correlation ID dan teruskan melalui gateway, BFF, dan log backend
• Tangkap trace agar Anda bisa melihat di mana waktu dihabiskan (gateway, BFF, layanan turunannya)
• Simpan log terstruktur (klien, endpoint, status code, latency, ukuran payload)
• Lacak beberapa metrik kunci per endpoint: error rate, p95 latency, throughput

Scaling juga terlihat berbeda. Gateway adalah titik choke bersama: ia harus menangani lonjakan dan endpoint populer tanpa menjadi bottleneck. BFF memungkinkan Anda scale per-klien, yang membantu ketika traffic web melonjak di jam kerja sementara mobile tetap stabil.

Dalam insiden, kegagalan bisa "bergerak" tergantung pola. Dengan gateway, masalah sering muncul sebagai 5xx menyeluruh atau kegagalan auth. Dengan BFF, isu mungkin terisolasi pada fitur satu klien. Buat runbook jelas tentang kemana harus melihat pertama, dan pertahankan perilaku fallback sederhana (mis. kembalikan respons tereduksi daripada timeout).

Cara memilih: proses keputusan langkah-demi-langkah sederhana

Memilih antara API gateway dan BFF kurang soal teori dan lebih soal apa yang klien Anda butuhkan tiap hari.

Alur keputusan praktis

1. Mulailah dari klien Anda, bukan server. Tuliskan setiap klien yang Anda dukung (aplikasi web, iOS, Android, API partner, admin internal) dan daftar apa yang dibutuhkan tiap layar utama. Jika tampilan "Customer details" butuh field dan pola panggilan berbeda antar klien, itu sinyal kuat untuk shaping spesifik-klien.

2. Pemetaan apa yang Anda miliki saat ini. Ambil endpoint sekarang dan tandai mana yang dibagi (operasi domain inti seperti orders, payments, users) versus mana yang dibentuk untuk presentasi (ringkasan dashboard, payload gabungan untuk "home screen"). Potongan bersama sebaiknya di backend inti. Potongan yang dibentuk untuk presentasi biasanya lebih cocok di BFF.

3. Putuskan di mana shaping dan aturan harus hidup. Jika Anda terutama butuh routing, auth, rate limit, caching, dan ekspos aman antara publik vs internal, gateway adalah rumah alami. Jika Anda butuh komposisi nyata (memanggil beberapa layanan, mengubah enam panggilan jadi satu, payload berbeda per app), tempatkan logika itu di kode BFF agar tetap dapat dites dan terbaca.

4. Pilih aturan versi dan deprecation yang bisa Anda patuhi. Contoh: "Tidak ada breaking change tanpa versi baru, dan setiap field yang dideprekasi tetap hidup selama 90 hari." Dengan pendekatan hanya gateway, Anda mungkin versi permukaan publik dan menerjemahkannya di belakang. Dengan BFF, seringkali Anda bisa menjaga API inti stabil dan hanya versi endpoint BFF per klien.

5. Rencanakan rollout dan ukur. Sebelum mengubah apa pun, ambil metrik baseline: p95 latency, jumlah panggilan per layar, ukuran payload, dan error rate. Luncurkan ke persentase kecil dulu, bandingkan sebelum dan sesudah, lalu perbesar.

Contoh sederhana: jika aplikasi mobile Anda rilis bulanan tetapi portal web rilis harian, BFF mobile kecil dapat melindungi aplikasi dari perubahan backend yang sering sementara web terus bergerak cepat.

Contoh: portal web + aplikasi mobile dengan kecepatan rilis berbeda

Bayangkan perusahaan dengan portal pelanggan di web dan aplikasi lapangan di mobile. Keduanya butuh data inti yang sama: customers, jobs, invoices, dan messages. Portal berubah mingguan. Aplikasi mobile lebih lambat karena review app store dan juga butuh bekerja pada sinyal lemah.

Rasanya muncul cepat. Pengguna mobile ingin respons ringkas, lebih sedikit panggilan, dan alur yang mendukung kerja offline (mis. unduh job hari ini sekali, lalu sinkronisasi perubahan kemudian). Portal web tidak masalah melakukan lebih banyak panggilan dan memuat layar yang lebih kaya karena selalu online dan lebih mudah diupdate.

Opsi A: API gateway di depan layanan yang stabil

Pilihan gateway-first menjaga layanan backend Anda sebagian besar tetap tak berubah. Gateway menangani autentikasi, routing, dan tweak kecil seperti header, rate limit, dan pemetaan field sederhana.

Versiasi tetap terutama di level API layanan. Itu baik: lebih sedikit bagian bergerak. Tapi juga berarti perubahan khusus mobile sering mendorong Anda ke versi besar seperti /v2 karena endpoint bawahnya dibagi.

Ekspos endpoint lebih jelas jika Anda menganggap gateway sebagai satu-satunya pintu publik. Endpoint internal tetap di baliknya, tapi Anda harus ketat tentang apa yang bisa dijangkau gateway dan apa yang dipublikasikan.

Opsi B: BFF mobile yang "berbicara mobile"

Dengan BFF mobile, aplikasi mobile berbicara ke endpoint yang dirancang untuk layar mobile dan alur sinkronisasi. BFF bisa mengagregasi data (detail job + customer + pesan terakhir), memangkas field, dan mengembalikan satu payload yang sesuai kebutuhan aplikasi.

Perubahannya:

• Versiasi menjadi lebih mudah per klien: Anda bisa versi BFF mobile tanpa memaksa portal web berubah
• Performa sering meningkat untuk mobile: lebih sedikit round trip dan respons lebih kecil
• Pemisahan publik vs internal menjadi lebih tegas: BFF bersifat publik, tapi BFF memanggil layanan internal yang tidak perlu diekspos

Kesalahan umum dan jebakan yang harus dihindari

Perangkap terbesar dalam debat API gateway vs BFF adalah menjadikan gateway sebagai mini backend. Gateway bagus untuk routing, auth, rate limit, dan shaping request sederhana. Saat Anda memasukinya dengan aturan bisnis, Anda mendapatkan logika tersembunyi yang sulit dites, susah debug, dan mudah rusak saat konfigurasi berubah.

BFF bisa salah arah di sisi lain: tim membuat satu BFF per layar atau per fitur, dan pemeliharaan meledak. BFF sebaiknya biasanya memetakan ke tipe klien (web, iOS, Android) atau area produk yang jelas, bukan tiap view UI. Kalau tidak, Anda menggandakan aturan di banyak tempat, dan versiasi menjadi pekerjaan penuh waktu.

Kesalahan versiasi sering muncul dari ekstrem. Jika Anda versi semua hal sejak hari pertama, Anda membekukan API terlalu awal dan menyimpan varian lama selamanya. Jika Anda tidak pernah versi, Anda akhirnya mengirim breaking change tanpa sengaja. Aturan sederhana yang efektif: jangan versi untuk perubahan aditif kecil, tapi buat versi saat Anda menghapus sesuatu atau mengubah makna.

Publik vs internal adalah area yang menyakitkan. Mengekspos layanan internal langsung ke internet (meski "sementara") menjadikan setiap perubahan internal potensi outage atau insiden keamanan. Jaga batas yang jelas: hanya gateway atau BFF yang publik, dan layanan internal tetap privat.

Masalah performa biasanya self-inflicted: payload berukuran besar, terlalu banyak round trip, dan tak ada anggaran latency. Contoh: aplikasi mobile mungkin hanya perlu status dan total order, tapi mendapat objek order penuh dengan setiap line item dan field audit, membuat tiap permintaan lambat di jaringan seluler.

Tanda peringatan yang harus diwaspadai:

• Konfigurasi gateway mereferensikan konsep bisnis seperti "refund eligibility" atau "VIP rules"
• BFF berkembang lebih cepat daripada jumlah klien yang dilayaninya
• Anda tidak bisa menjelaskan strategi versi API dalam satu kalimat
• Endpoint layanan internal dapat diakses dari internet publik
• Respons terus tumbuh karena "mungkin berguna nanti"

Checklist cepat dan langkah selanjutnya

Jika Anda buntu soal keputusan API gateway vs BFF, fokuslah pada apa yang akan rusak duluan di dunia nyata: rilis, payload, dan batas keamanan.

Checklist singkat

Jika Anda menjawab "tidak" untuk beberapa pertanyaan ini, setup saat ini kemungkinan akan menyulitkan saat klien Anda bertumbuh:

• Bisakah Anda mengubah satu layanan backend tanpa memaksa setiap klien memperbarui di minggu yang sama?
• Apakah ada batas jelas antara endpoint publik (aman untuk internet) dan internal (hanya untuk sistem tepercaya)?
• Apakah web dan mobile menerima hanya yang mereka perlukan (bukan respons "kitchen sink" besar)?
• Dapatkah Anda meluncurkan perubahan secara bertahap (persentase kecil dulu) dan melihat error, latency, serta trafik tidak biasa dengan cepat?
• Apakah Anda tahu siapa yang memiliki kontrak untuk tiap endpoint dan siapa yang menyetujui breaking change?

Langkah selanjutnya

Ubah jawaban menjadi rencana. Tujuannya bukan arsitektur sempurna, tapi lebih sedikit kejutan saat Anda merilis.

Tuliskan kontrak API dalam bahasa sederhana (input, output, kode error, apa yang boleh berubah). Pilih model kepemilikan: siapa yang bertanggung jawab kebutuhan klien (web/mobile) dan siapa yang memegang layanan domain inti. Tentukan di mana versiasi berada (per klien, atau terpusat) dan tetapkan aturan deprecation yang akan Anda patuhi.

Tambahkan monitoring dasar sebelum refactor besar: request rate, p95 latency, error rate, dan endpoint teratas berdasarkan ukuran payload. Buat prototipe alur klien paling berisiko dulu.

Jika Anda membangun dengan AppMaster (appmaster.io), satu pendekatan praktis adalah menyimpan logika bisnis inti dan model data di backend yang digenerate, lalu menambahkan lapisan gateway tipis atau BFF hanya di tempat klien benar-benar butuh shaping payload atau isolasi rilis.

Jika checklist terasa sulit dijawab, anggap itu sinyal untuk menyederhanakan kontrak dan mengencangkan pemisahan publik vs internal sebelum menambah lebih banyak endpoint.