Menguasai Fetch API & Axios untuk Akses Data Backend

Di era aplikasi web yang kian dinamis, data dari backend adalah “bahan bakar” utama yang menggerakkan tampilan di layar pengguna. Namun, cara kita mengambil, mengolah, dan menampilkan data itu bisa menjadi perbedaan antara aplikasi yang responsif dan mudah dirawat, dengan aplikasi yang rapuh dan sulit dikembangkan. Di sinilah Fetch API dan Axios masuk sebagai dua senjata andalan JavaScript untuk berkomunikasi dengan server.

Keduanya sama‑sama mampu mengirim permintaan HTTP, mengambil data JSON, hingga menangani error. Tapi di balik fungsi yang tampak mirip, Fetch API dan Axios menyimpan karakteristik, kelebihan, dan kekurangan masing‑masing. Memahami perbedaan ini bukan hanya soal “pakai yang mana”, melainkan bagaimana memilih alat yang tepat untuk kebutuhan spesifik aplikasi Anda-apakah itu proyek kecil tanpa dependensi tambahan, atau aplikasi skala besar yang menuntut penanganan request yang lebih rapi dan konsisten.

Artikel ini akan mengajak Anda menyelami Fetch API dan Axios secara bertahap: mulai dari konsep dasar, contoh penggunaan, pola penanganan respons dan error, hingga praktik yang lebih lanjut seperti interceptors dan konfigurasi global. Dengan begitu, Anda tidak hanya sekadar “bisa memakainya”, tetapi benar‑benar menguasai cara keduanya bekerja untuk mengakses data backend secara efisien dan terstruktur.

Membedah Fondasi Fetch API dan Axios untuk Permintaan HTTP yang Andal

Kalau mau bikin permintaan HTTP yang benar‑benar andal, kita perlu paham dulu “batu bata”-nya: bagaimana Fetch API dan Axios menangani request, response, dan error di balik layar. Fetch bekerja langsung di atas browser API, lebih “low level”, dan mengembalikan Promise yang harus kita olah sendiri, termasuk memanggil .json() dan memeriksa status HTTP. Axios, di sisi lain, datang sebagai lapisan yang lebih “siap pakai”: otomatis mengonversi JSON, punya sistem interceptor, dan konsisten di browser maupun Node.js. Di sinilah fondasi pentingnya: bukan sekadar “pakai yang mana”, tapi paham bagaimana keduanya mengelola siklus hidup permintaan – dari membangun request, mengirim, menerima, sampai memproses hasil atau error.

• Fetch API: native, ringan, tapi butuh sedikit lebih banyak kode untuk penanganan error dan konfigurasi lanjutan.
• Axios: kaya fitur, konfigurasi global gampang, dan cocok untuk proyek yang butuh struktur request yang rapi.
• Keduanya: sama‑sama berbasis Promise, bisa dipadukan dengan async/await, dan mendukung pola arsitektur modern seperti service layer.

Contoh sederhana perbedaan cara keduanya membangun dasar request ke backend:

// Fondasi request dengan Fetch
async function getUsersWithFetch() {
  const response = await fetch('https://api.example.com/users');
  if (!response.ok) {
    throw new Error(`Error: ${response.status}`);
  }
  const data = await response.json();
  return data;
}

// Fondasi request dengan Axios
import axios from 'axios';

async function getUsersWithAxios() {
  const { data } = await axios.get('https://api.example.com/users');
  return data;
}

Strategi Penanganan Error dan Timeout agar Integrasi Frontend Backend Tetap Tangguh

Di dunia nyata, request ke server itu nggak selalu mulus-kadang lambat, kadang gagal total. Di sinilah pentingnya menyiapkan fallback dan strategi retry yang masuk akal. Misalnya, kamu bisa membedakan error karena jaringan, error HTTP (seperti 404 atau 500), dan error parsing data. Lalu, tampilkan pesan yang jelas ke pengguna, bukan sekadar “Terjadi kesalahan”. Untuk request yang krusial, kamu bisa pakai pola exponential backoff: coba ulang beberapa kali dengan jeda yang makin panjang, tapi tetap batasi jumlah percobaan supaya aplikasi nggak jadi agresif ke server.

• Gunakan timeout yang realistis, jangan terlalu pendek atau terlalu panjang
• Selalu sediakan UI loading state, error state, dan empty state
• Log error di frontend (dan kalau bisa di-backend) untuk debugging
• Bedakan error untuk developer (detail) dan error untuk user (sederhana)
• Manfaatkan cancel request untuk mencegah race condition

Di sisi kode, baik Fetch API maupun Axios mendukung pendekatan ini dengan cukup fleksibel. Kamu bisa membungkus request dalam fungsi utilitas yang sudah mengurus timeout, retry, dan normalisasi error supaya semua pemanggilan API punya pola yang konsisten. Misalnya, Axios memungkinkan konfigurasi global untuk timeout dan interceptor, sementara Fetch bisa dipasangkan dengan AbortController untuk membatalkan request yang sudah tidak relevan (misalnya user ganti halaman). Intinya, jangan cuma fokus ke “data berhasil diambil”, tapi juga pikirkan: “kalau gagal, aplikasi gue tetap terasa tangguh nggak?”

Optimasi Performa dengan Caching Respons dan Konfigurasi Interceptor yang Tepat

Sering kali masalah bukan di API-nya, tapi di cara kita “bolak-balik” minta data yang sama. Di sinilah caching respons jadi penyelamat. Dengan menyimpan hasil respons sementara di memori, localStorage, atau IndexedDB, kita bisa menghindari permintaan berulang yang bikin aplikasi terasa berat. Misalnya, data konfigurasi, daftar kategori, atau profil user yang jarang berubah sangat cocok untuk di-cache. Saat menggunakan Fetch API, kamu bisa membangun lapisan kecil di atas fetch yang ngecek cache dulu sebelum memanggil jaringan. Di sisi lain, Axios bikin ini lebih manis dengan dukungan interceptor, sehingga kamu bisa menyuntikkan logika caching di satu tempat terpusat dan semua request otomatis ikut aturan main.

• Kurangi request berulang untuk endpoint yang isinya jarang berubah.
• Gunakan interceptor untuk menambah header, token, logging, dan penanganan error global.
• Bedakan strategi antara data statis (boleh di-cache lama) dan data sensitif (sebaiknya real-time).
• Kombinasikan cache + retry agar aplikasi tetap responsif saat jaringan sedang tidak stabil.

“`js
// Contoh sederhana: interceptor Axios untuk caching respons GET
import axios from “axios”;

const cache = new Map();

const api = axios.create({
baseURL: “https://api.example.com”,
});

// Request interceptor: cek cache sebelum kirim request
api.interceptors.request.use((config) => {
if (config.method === “get”) {
const key = config.url + JSON.stringify(config.params || {});
if (cache.has(key)) {
// Simulasi respons dari cache dengan membatalkan request jaringan
config.adapter = () =>
Promise.resolve({
data: cache.get(key),
status: 200,
statusText: “OK (from cache)”,
headers: {},
config,
request: null,
});
}
}
return config;
});

// Response interceptor: simpan ke cache
api.interceptors.response.use((response) => {
if (response.config.method === “get”) {
const key =
response.config.url + JSON.stringify(response.config.params || {});
cache.set(key, response.data);
}
return response;
});
“`

Pola Terbaik Organisasi Kode dan Abstraksi Layer API dalam Proyek Skala Kecil hingga Besar

Di proyek kecil, sering kali kita langsung memanggil fetch atau axios di dalam komponen UI atau halaman. Awalnya terasa praktis, tapi makin lama, file jadi gemuk dan susah dirapikan. Jauh lebih sehat kalau sejak awal memisahkan logika akses data ke dalam folder seperti /services atau /api. Di situ kita bikin fungsi-fungsi kecil yang jelas tujuannya: misalnya getUserProfile(), updateCart(), dan seterusnya. Komponen UI cukup “minta” data lewat fungsi itu, tanpa peduli apakah di baliknya pakai Fetch API atau Axios. Dengan cara ini, kalau suatu saat mau ganti library HTTP, kamu cukup sentuh lapisan servisnya saja, bukan bongkar semua komponen. Kuncinya: satu file, satu tanggung jawab, dan jangan campur-campur urusan presentasi dengan urusan jaringan.

• Small App: 1-2 file service sederhana, langsung dipanggil komponen.
• Medium App: pisahkan per domain, misalnya userService, productService, authService.
• Large App: tambah lapisan adapter atau repository, misalnya /repositories yang membungkus Axios/Fetch.

Di level abstraksi yang lebih dalam, ada baiknya memisahkan tiga lapisan: HTTP client (Fetch/Axios murni), service (aturan bisnis tipis), dan UI. HTTP client bertugas menangani hal-hal seperti base URL, header, token, dan interceptor error. Lapisan service fokus pada “bahasa bisnis”: misalnya, “login user”, “ambil daftar produk populer”, bukan “GET /v1/products?popular=true”. Di atas itu, UI hanya konsumsi fungsi yang sudah rapi, sehingga refactor besar-besaran di backend atau aturan otentikasi tidak membuat komponen front-end berantakan. Pendekatan berlapis ini kadang terasa lebay di awal, tapi ketika API mulai banyak dan tim makin besar, struktur seperti ini yang menyelamatkan dari codebase yang kusut dan sulit di-maintain.

In Retrospect

Pada akhirnya, baik Fetch API maupun Axios hanya sebatas alat-kekuatan sesungguhnya ada pada cara Anda merangkai keduanya dalam alur kerja yang rapi, konsisten, dan mudah dirawat. Begitu Anda memahami pola dasarnya: membuat request, menangani response, mengelola error, dan mengatur konfigurasi, perbedaan sintaks hanyalah detail kecil.

Setelah ini, Anda bisa mulai bereksperimen:
– Membangun lapisan helper untuk request yang lebih bersih.
– Menggabungkan Fetch atau Axios dengan state management di frontend.
– Mengoptimalkan performa lewat caching, debouncing, atau abort request.

Semakin sering Anda berlatih, semakin intuitif proses komunikasi dengan backend akan terasa. Pada titik itu, mengambil data, mengirim form, atau menyambungkan aplikasi ke berbagai layanan eksternal bukan lagi hambatan-melainkan bagian alami dari cara Anda membangun produk di web.