API Gateway vs BFF: Trade-off Skala, Biaya, dan Maintainability

API Gateway vs BFF bukan pilihan yang selalu saling menggantikan. API Gateway biasanya cocok sebagai pintu masuk terpusat untuk routing, autentikasi awal, rate limiting, TLS termination, dan kontrol akses lintas layanan. Backend-for-Frontend atau BFF lebih tepat ketika setiap klien, misalnya web, iOS, Android, atau dashboard admin, membutuhkan komposisi data, bentuk respons, dan alur autentikasi yang berbeda.

Untuk aplikasi web/mobile yang mulai tumbuh, keputusan utamanya adalah: apakah masalah Anda ada di traffic management dan kontrol edge, atau di client-specific orchestration? Jika klien hanya perlu meneruskan request ke service yang tepat, API Gateway biasanya cukup. Jika frontend sering melakukan banyak request, memproses data domain di sisi klien, atau terhambat karena satu API harus melayani terlalu banyak jenis UI, BFF sering menjadi desain yang lebih maintainable.

Definisi Singkat: API Gateway dan BFF

API Gateway

API Gateway adalah lapisan entry point untuk API. Ia berada di depan service internal dan menangani concern yang relatif umum untuk banyak endpoint, seperti:

• Routing request ke service yang sesuai.
• Validasi token atau integrasi dengan identity provider.
• Rate limiting dan proteksi dasar terhadap abuse.
• TLS termination, CORS policy, header normalization.
• Request/response logging, metrics, dan tracing entry point.
• Transformasi ringan, misalnya menambah header tenant ID atau menghapus header internal.

Gateway idealnya tidak berisi banyak logika produk. Semakin banyak business logic dimasukkan ke gateway, semakin sulit perubahan domain diuji, dideploy, dan dimiliki oleh tim yang tepat.

Backend-for-Frontend (BFF)

BFF adalah backend yang dibuat khusus untuk kebutuhan satu jenis frontend atau satu kelompok frontend yang sangat mirip. Contohnya:

• Web BFF untuk aplikasi React/Vue/Angular di browser.
• Mobile BFF untuk iOS dan Android dengan kebutuhan payload lebih hemat.
• Admin BFF untuk dashboard internal dengan permission dan workflow berbeda.

BFF biasanya bertugas mengagregasi beberapa service, menyederhanakan shape data, menyembunyikan kompleksitas domain dari UI, dan mengoptimalkan round trip. BFF bukan sekadar proxy; ia adalah lapisan orkestrasi yang sengaja mengikuti kebutuhan pengalaman pengguna di frontend tertentu.

Kapan Cukup Memakai API Gateway?

Gunakan API Gateway saja ketika masalah utama Anda adalah mengelola akses ke banyak service, bukan mengubah cara frontend mengonsumsi data. Ini umum pada fase awal ketika jumlah klien masih sedikit dan kontrak API masih sederhana.

Indikasi gateway saja sudah cukup

• Frontend hanya membutuhkan satu atau dua API call untuk memuat halaman utama.
• Struktur respons dari backend sudah cocok untuk UI tanpa transformasi besar.
• Web dan mobile dapat berbagi kontrak API yang sama tanpa banyak percabangan.
• Tim backend masih kecil dan belum siap memelihara service tambahan.
• Concern yang dibutuhkan adalah routing, auth, rate limit, CORS, atau observability dasar.

Contoh pada aplikasi SaaS tahap awal: frontend memanggil endpoint /projects, /invoices, dan /users/me. Setiap endpoint langsung dimiliki oleh service yang jelas. Selama tidak ada kebutuhan agregasi kompleks dan performa masih baik, menambah BFF bisa menjadi overhead yang belum perlu.

Batasan gateway sebagai solusi tunggal

Gateway mulai menjadi tidak ideal ketika ia dipakai untuk menggabungkan data dari banyak service, menerapkan aturan presentasi, atau membuat variasi respons berdasarkan platform. Beberapa gateway mendukung plugin atau scripting, tetapi menaruh logika produk di sana sering menimbulkan masalah:

• Testing business logic lebih sulit dibanding service biasa.
• Ownership kabur: apakah perubahan dimiliki tim platform, backend, atau frontend?
• Deploy gateway menjadi terlalu berisiko karena perubahan satu fitur dapat memengaruhi semua traffic.
• Debugging lebih rumit jika transformasi terjadi di banyak plugin.

Prinsip praktis: gunakan gateway untuk concern lintas sistem; gunakan BFF untuk concern spesifik pengalaman frontend.

Kapan BFF Lebih Tepat?

BFF menjadi berguna ketika frontend mulai menanggung terlalu banyak kompleksitas backend. Tanda yang sering terlihat adalah halaman UI membutuhkan banyak request paralel, frontend harus menggabungkan data dari beberapa domain, atau satu API publik dipaksa melayani kebutuhan web dan mobile yang berbeda.

Indikasi Anda mulai membutuhkan BFF

• Satu halaman membutuhkan 5-10 request ke service berbeda sebelum bisa tampil utuh.
• Mobile membutuhkan payload lebih kecil, tetapi web membutuhkan detail lebih kaya.
• Frontend berisi banyak logika mapping domain, fallback, dan permission.
• Perubahan UI sering menunggu perubahan beberapa tim backend sekaligus.
• Anda perlu menyembunyikan detail service internal dari klien publik.
• Versi API untuk web dan mobile bergerak dengan kecepatan berbeda.

Contoh e-commerce: halaman detail produk di mobile perlu nama produk, foto, harga, promo, estimasi ongkir, stok, rating, dan rekomendasi. Data tersebut mungkin berasal dari catalog service, pricing service, inventory service, review service, dan recommendation service. Tanpa BFF, aplikasi mobile harus memanggil banyak endpoint, menangani partial failure, dan memahami terlalu banyak kontrak internal.

Dengan BFF, mobile cukup memanggil satu endpoint seperti GET /mobile/products/{id}/summary. BFF melakukan agregasi, memilih field yang relevan, menerapkan fallback, lalu mengembalikan payload yang siap digunakan UI.

Contoh sederhana endpoint BFF

Contoh berikut menunjukkan pola agregasi di BFF. Kode ini bukan template produksi lengkap, tetapi menggambarkan pemisahan tanggung jawab: BFF mengambil data dari beberapa service dan membentuk respons khusus mobile.

app.get('/mobile/products/:id/summary', async (req, res, next) => {
  const productId = req.params.id;
  const authHeader = req.headers.authorization;

  try {
    const [product, price, inventory] = await Promise.all([
      catalogClient.getProduct(productId, { authorization: authHeader }),
      pricingClient.getCurrentPrice(productId, { authorization: authHeader }),
      inventoryClient.getAvailability(productId, { authorization: authHeader })
    ]);

    res.json({
      id: product.id,
      name: product.name,
      imageUrl: product.primaryImageUrl,
      price: {
        amount: price.amount,
        currency: price.currency,
        discountLabel: price.discountLabel ?? null
      },
      availability: {
        inStock: inventory.quantity > 0,
        message: inventory.quantity > 0 ? 'Tersedia' : 'Stok habis'
      }
    });
  } catch (error) {
    next(error);
  }
});

Dalam implementasi produksi, tambahkan timeout per downstream call, retry terbatas untuk error transient, circuit breaker bila diperlukan, validasi authorization, structured logging, metrics, distributed tracing, serta strategi partial response bila beberapa data tidak kritis.

Tabel Trade-off API Gateway vs BFF

Dampak Arsitektur pada Latency dan Performa

Kesalahan umum dalam membandingkan API Gateway dan BFF adalah hanya menghitung jumlah hop. Memang, BFF menambah satu lapisan jaringan. Namun pada aplikasi web/mobile, performa yang dirasakan pengguna sering lebih dipengaruhi oleh jumlah round trip, ukuran payload, dan pola dependency antar request.

Gateway dan latency

Gateway menambah overhead untuk menerima, memvalidasi, dan meneruskan request. Jika gateway hanya melakukan routing dan validasi ringan, overhead biasanya lebih mudah dikontrol. Masalah muncul jika gateway mulai melakukan transformasi berat, memanggil service tambahan, atau menjalankan plugin yang mahal untuk setiap request.

BFF dan latency

BFF dapat menurunkan latency end-to-end ketika ia menggantikan banyak request dari client menjadi satu request agregat. Manfaat ini terasa pada mobile network yang latensinya lebih bervariasi. Namun BFF juga bisa memperburuk performa jika:

• Downstream call dilakukan berurutan padahal bisa paralel.
• Tidak ada timeout sehingga satu service lambat menahan seluruh respons.
• Payload agregat terlalu besar karena semua field dikirim tanpa seleksi.
• Caching tidak dipikirkan, terutama untuk data relatif statis seperti katalog atau konfigurasi UI.

Praktik yang biasanya membantu adalah melakukan request paralel untuk data independen, memberi timeout berbeda untuk data kritis dan non-kritis, mengembalikan partial response untuk komponen opsional, serta mencatat latency per downstream dependency.

Autentikasi, Authorization, dan Security Boundary

API Gateway sering menjadi tempat yang tepat untuk autentikasi awal: memvalidasi token, menolak request tanpa credential, menerapkan rate limit, dan menambahkan metadata identitas ke header internal. Namun gateway sebaiknya tidak menjadi satu-satunya tempat authorization domain.

Service internal tetap perlu memvalidasi hak akses yang relevan dengan domainnya. Misalnya, order service harus memastikan pengguna memang boleh melihat order tertentu. BFF dapat membantu menerjemahkan konteks pengguna menjadi kebutuhan UI, tetapi tidak boleh menjadi satu-satunya pelindung data sensitif jika downstream service juga dapat dipanggil oleh jalur lain.

Pola yang aman

• Gateway memvalidasi token dan menerapkan policy global.
• BFF meneruskan konteks identitas yang diperlukan ke service internal.
• Service domain melakukan authorization berdasarkan aturan domain.
• Log tidak menyimpan token mentah, password, atau data sensitif yang tidak perlu.
• Gunakan correlation ID agar request dapat dilacak dari gateway ke BFF dan service internal.

Versioning API: Siapa yang Harus Stabil?

Pada sistem yang tumbuh, versioning sering menjadi alasan kuat untuk memakai BFF. API domain sebaiknya stabil terhadap model bisnis, sementara API frontend boleh lebih dekat dengan kebutuhan layar dan flow pengguna. Jika satu endpoint publik dipaksa melayani semua klien, perubahan kecil pada mobile dapat mengganggu web, dan sebaliknya.

Dengan BFF, Anda dapat membuat kontrak yang lebih spesifik, misalnya:

• /web/subscriptions/checkout-page untuk halaman checkout web.
• /mobile/subscription-offers untuk penawaran ringkas di mobile.
• /admin/customers/{id}/billing-overview untuk dashboard support.

Ini tidak berarti setiap halaman harus punya endpoint sendiri. Gunakan granularitas yang masuk akal: endpoint BFF sebaiknya mewakili use case atau komponen besar yang stabil, bukan setiap perubahan kecil layout.

Observability dan Debugging

API Gateway memberi gambaran traffic masuk: request per route, status code, latency, dan error di edge. Ini berguna untuk melihat apakah masalah terjadi sebelum request masuk ke sistem internal. Namun gateway saja tidak cukup untuk memahami mengapa halaman tertentu lambat atau gagal sebagian.

BFF memberi observability pada level pengalaman pengguna. Anda bisa mencatat bahwa endpoint /mobile/products/{id}/summary lambat karena pricing service, bukan karena catalog service. Informasi ini penting saat sistem terdiri dari banyak dependency.

Checklist observability minimum

• Gunakan correlation ID atau trace ID dari gateway sampai downstream service.
• Catat latency total dan latency per dependency di BFF.
• Pisahkan error karena validasi input, authorization, timeout, dan downstream failure.
• Buat dashboard per endpoint penting, bukan hanya rata-rata global.
• Tambahkan alert untuk error rate dan latency p95/p99 bila infrastruktur observability mendukungnya.

Untuk debugging, hindari hanya melihat log gateway. Jika BFF melakukan agregasi, log yang paling penting sering berada di BFF: dependency mana yang dipanggil, berapa lama, status apa yang dikembalikan, dan apakah fallback digunakan.

Deployment, Ownership Tim, dan Biaya Operasional

Menambah BFF berarti menambah komponen yang harus dipelihara. Ada repository atau modul baru, pipeline CI/CD, konfigurasi environment, secret management, monitoring, autoscaling, dan tanggung jawab on-call. Jika tim belum siap, BFF dapat mempercepat pengembangan frontend di awal tetapi menjadi beban operasional setelah beberapa bulan.

Ownership yang sehat

BFF paling efektif ketika dimiliki oleh tim yang memahami kebutuhan frontend dan kontrak backend. Pada organisasi kecil, ini bisa berupa tim full-stack. Pada organisasi lebih besar, bisa berupa tim produk yang memiliki web BFF atau mobile BFF. Hindari situasi di mana BFF dimiliki oleh tim platform murni, tetapi semua perubahan datang dari tim fitur; pola ini sering membuat BFF menjadi bottleneck.

Biaya yang perlu dihitung

• Compute dan memory untuk service BFF.
• Biaya observability: log volume, metrics, tracing.
• Waktu engineer untuk testing kontrak dan debugging downstream.
• Pipeline deployment dan environment tambahan.
• Risiko duplikasi logic antar BFF jika governance lemah.

API Gateway juga memiliki biaya, terutama jika menggunakan produk managed atau menjalankan gateway cluster sendiri. Namun dari sisi maintainability, biaya terbesar gateway biasanya muncul ketika konfigurasi dan plugin berkembang menjadi tempat business logic tersembunyi.

Contoh Skenario: E-commerce dan SaaS

E-commerce yang mulai tumbuh

Awalnya, aplikasi e-commerce memiliki monolith backend dan satu frontend web. Gateway digunakan untuk TLS, routing, dan autentikasi. Ketika mobile app diluncurkan, tim mulai melihat masalah: halaman produk memanggil banyak endpoint, payload terlalu besar, dan release mobile harus kompatibel dengan versi lama yang masih dipakai pengguna.

Dalam kondisi ini, pola yang masuk akal adalah mempertahankan API Gateway sebagai entry point dan menambahkan Mobile BFF. Gateway tetap menangani auth dan routing. Mobile BFF menangani komposisi data produk, harga, stok, promo, dan rekomendasi. Web dapat tetap memakai API domain langsung atau memiliki Web BFF jika kebutuhannya juga mulai kompleks.

SaaS B2B dengan dashboard kompleks

Pada SaaS B2B, dashboard admin mungkin membutuhkan data subscription, billing, usage, team member, permission, dan audit log. Jika frontend memanggil semua service langsung, UI menjadi rapuh terhadap perubahan kontrak backend. Admin BFF dapat menyediakan endpoint yang sesuai dengan workflow dashboard, misalnya ringkasan akun pelanggan atau status pembayaran.

Namun untuk API publik yang digunakan integrator eksternal, BFF bukan pengganti desain API yang stabil. Integrator biasanya membutuhkan kontrak domain yang konsisten, dokumentasi jelas, dan backward compatibility. Dalam kasus ini, gateway plus API domain yang dirancang baik tetap penting.

Anti-pattern yang Perlu Dihindari

• Gateway menjadi tempat business logic. Jika gateway berisi aturan diskon, mapping status order, atau permission kompleks, pertimbangkan memindahkannya ke service domain atau BFF.
• Satu BFF untuk semua frontend. Ini sering berubah menjadi backend monolith baru. Jika web dan mobile sangat berbeda, pisahkan berdasarkan kebutuhan dan ownership.
• BFF hanya meneruskan request tanpa nilai tambah. Jika BFF hanya proxy tipis ke satu service, mungkin gateway sudah cukup.
• Duplikasi aturan domain di banyak BFF. Aturan seperti perhitungan invoice, eligibility promo, atau status subscription sebaiknya tetap berada di service domain.
• Tidak ada timeout dan fallback. BFF yang mengagregasi banyak service rentan mengalami cascading failure jika dependency lambat.
• Versioning berdasarkan layout terlalu detail. Endpoint BFF sebaiknya mengikuti use case yang cukup stabil, bukan setiap perubahan pixel di UI.
• Observability setelah terjadi insiden. Tanpa trace dan metrics per dependency, BFF sulit dioperasikan.

Checklist Keputusan Sebelum Migrasi ke BFF

Sebelum membuat BFF, jawab pertanyaan berikut secara jujur. Jika sebagian besar jawabannya mengarah ke kompleksitas frontend dan variasi klien, BFF layak dipertimbangkan. Jika tidak, optimalkan gateway dan API domain terlebih dahulu.

1. Apakah satu layar utama membutuhkan banyak request ke service berbeda?
2. Apakah frontend berisi banyak logic agregasi, filtering, mapping, atau fallback?
3. Apakah web dan mobile membutuhkan bentuk respons yang berbeda secara signifikan?
4. Apakah payload saat ini terlalu besar untuk mobile atau koneksi lambat?
5. Apakah perubahan UI sering terhambat karena harus mengubah banyak service backend?
6. Apakah tim yang akan memiliki BFF jelas dan siap melakukan on-call?
7. Apakah sudah ada strategi autentikasi, authorization, dan propagation identity?
8. Apakah gateway tetap dipakai untuk concern edge seperti rate limiting dan TLS?
9. Apakah observability end-to-end sudah tersedia atau akan dibangun bersamaan?
10. Apakah ada rencana mencegah duplikasi business logic antar BFF?
11. Apakah kontrak BFF akan diuji dengan contract test atau integration test?
12. Apakah biaya deployment, monitoring, dan operasional tambahan dapat diterima?

Rekomendasi Praktis

Untuk aplikasi yang baru mulai tumbuh, jangan langsung memilih salah satu secara ekstrem. Pola yang umum dan sehat adalah memakai API Gateway sebagai entry point standar, lalu menambahkan BFF hanya untuk klien atau area produk yang benar-benar membutuhkan orkestrasi spesifik.

• Mulai dari gateway jika kebutuhan utama adalah routing, autentikasi awal, rate limiting, dan kontrol akses umum.
• Tambahkan BFF ketika frontend mulai melakukan agregasi kompleks, payload perlu disesuaikan per platform, atau release web/mobile membutuhkan kontrak berbeda.
• Jaga service domain tetap menjadi sumber business logic agar BFF tidak menduplikasi aturan inti bisnis.
• Investasikan observability sejak awal karena BFF menambah dependency chain yang harus bisa dilacak.
• Pastikan ownership jelas; arsitektur yang benar secara teknis tetap gagal jika tidak ada tim yang bertanggung jawab.

Kesimpulannya, API Gateway vs BFF adalah keputusan tentang batas tanggung jawab. Gateway menyelesaikan masalah akses dan traffic di tepi sistem. BFF menyelesaikan masalah pengalaman klien dan orkestrasi data. Pada skala yang sehat, keduanya sering digunakan bersama: gateway sebagai pintu masuk terkontrol, BFF sebagai lapisan khusus untuk membuat web/mobile lebih cepat dikembangkan, lebih mudah diobservasi, dan lebih maintainable.