Content: Backends for Frontends

BFF

Yap, ini tentang Frontend bukan Friend. Jadi, beberapa waktu lalu fokus belajar data fetching dari REST API server dan beberapa kali mencoba bikin sendiri. Ternyata ga semudah yang ada di tutorial, kemungkinan karena aku nyoba pakai RUST entah warp-postgre stack atau rocket-diesel stack. Lalu aku nemu prest alias postgres.rest yang package nya single binary mirip hugo tapi tetap bisa dikustom. Namun, masalahnya bukan tentang terkoneksi ke REST API itu sendiri melainkan bagaimana mengkonsumsi arsitektur penyedia data yang terus berevolusi. Kita tahu arsitektur monolitik atau terkoneksi langsung kepada penyedia data, membuat frontend bergantung terhadap arsitektur yang tersedia. Perkembangan linier ini semakin sulit berjalan bareng kalau data bertambah banyak variasinya atau arsitektur penyedia data terus berubah. Sebenarnya normal jika sebuah arsitektur frontend memiliki server gateway untuk fetching data dari berbagai endpoint atau dari server berbeda. Berhubung biasanya kita menulis frontend dengan Javascript atau Java maka gateway ini memiliki tugas yang berbeda daripada REST server. Arsitektur inilah yang disebut backend for frontend


async function getContent(url, data, headers) {
  return fetch(url, {
    method: 'GET',
    data: data || undefined,
    cache: 'no-cache',
    headers: new Headers(headers || undefined),
  })
    .then((response) => {
      if (response.ok) {
        return response.json();
      }
      throw response;
    })
    .catch((reason) => {
      throw reason;
    });
}

getContent('https://endpoint.web/api/v2')

Decentralize, decoupled, loose coupled. Kita sering sekali menemui frasa aneh itu, tapi kita sering lupa apa yang mendasari atau kenapa ini menjadi kebutuhan. Pemisahan backend dan frontend sendiri sudah terlalu memusingkan, lalu kenapa? Kenapa kita harus bersinggungan dengan berbagai micro-services di sisi backend? Jawabannya tergantung lingkungan pengembangan yang akan dikerjakan, sebenarnya solusi ditemukan karena permasalahan. Kenapa tidak mencoba memudahkan pekerjaan dari awal? Dalihnya mungkin untuk menanggulangi perkembangan konten tanpa merusak kode frontend yang sudah berjalan. Daripada data massive dan server overhead lalu semua aplikasi klien down, lebih baik kita pecah sumbernya sesuai kebutuhan, bukankah filosofi unix sudah terbukti ampuh berjalan beberapa dekade ini?


Copied!