Ada dua cara untuk membuat permintaan HTTP dalam JavaScript, yang selalu menjadi bahan perdebatan tanpa henti, dan perdebatan tersebut biasanya berfokus pada aspek yang paling tidak penting.
Ukuran bundel, keanggunan sintaksis, apakah suatu dependensi memang diperlukan — semua itu hanyalah preferensi, dan orang-orang yang rasional bisa memiliki pandangan yang berbeda-beda. Satu perbedaan bukanlah soal preferensi, dan hal ini menimbulkan bug nyata dalam kode produksi: fetch tidak membatalkan janji (promise) yang dijanjikannya ketika server mengembalikan status kesalahan. Kode 404 tetap dieksekusi. Kode 500 tetap dieksekusi. Fungsi .catch() Anda tidak pernah dijalankan, dan kode terus berjalan seolah-olah semuanya berfungsi dengan baik.
Itu adalah perilaku yang didokumentasikan, bukan sekadar keanehan, dan hal inilah yang harus dipahami sebelum hal lainnya.
Kami adalah Geonode dan kami menjual proxy, jadi catatan terkait topik ini ada di sini: terdapat perbedaan nyata dan kurang didokumentasikan antara keduanya terkait dukungan proxy di Node, dan hal ini sering menjebak orang. fetch bawaan di Node tidak mendeteksi variabel lingkungan proxy standar, yang mengejutkan hampir semua orang yang menganggapnya berperilaku seperti curl. Hal ini memiliki bagian tersendiri, dan jika Anda tidak merutekan permintaan melalui proxy, Anda dapat melewatkannya sepenuhnya — sebagian besar orang sebaiknya melakukannya.
Sebuah catatan kecil, karena hal ini memengaruhi siapa pun yang mengikuti tautan lama: Dokumentasi Axios telah dipindahkan. axios-http.com kini dialihkan ke axios.rest. Bookmark dan jawaban di Stack Overflow yang mengarah ke domain lama masih berfungsi melalui pengalihan tersebut, tetapi lokasi kanoniknya telah berubah.
Semua penjelasan di bawah ini mengenai perilaku berasal dari MDN dan dokumentasi Axios sendiri, bukan dari ingatan siapa pun.
Perbedaan yang Menyebabkan Bug Sebenarnya
Mulailah dari sini, karena ini adalah satu-satunya perbedaan yang tidak sekadar soal selera.
Apa yang Dikatakan MDN
Langsung dari dokumentasi:
"Sebuah janji ``fetch()`
hanya akan ditolak jika permintaan gagal, misalnya karena URL permintaan yang salah format atau kesalahan jaringan. Sebuah janji ``fetch()
*tidak* akan ditolak jika server merespons dengan kode status HTTP yang menandakan kesalahan (seperti404`
, 504
, dll.). Sebaliknya, penangan ``then()`
harus memeriksa properti ``Response.ok
dan/atau ``Response.status
`."
Penekanan pada kata tidak merupakan penekanan dari MDN sendiri.
Apa Artinya dalam Praktik
// Looks correct. Is not.
try {
const res = await fetch('/api/user/999');
const user = await res.json();
showUser(user); // runs on a 404
} catch (err) {
showError(err); // never runs on a 404
}
Server mengembalikan kode status 404 dengan isi pesan kesalahan. fetch
berhasil diproses. res.json()
mengurai objek kesalahan tersebut. showUser
menerima sesuatu yang bukan pengguna, dan kegagalan tersebut muncul kemudian, di tempat lain, sebagai kesalahan yang membingungkan mengenai properti yang tidak terdefinisi.
Versi yang benar:
try {
const res = await fetch('/api/user/999');
if (!res.ok) {
throw new Error(`HTTP ${res.status}`);
}
const user = await res.json();
showUser(user);
} catch (err) {
showError(err);
}
Tiga baris tambahan, dan baris-baris ini wajib ada di setiap permintaan yang Anda tulis.
Bagaimana Axios Berfungsi
Secara default, Axios menolak permintaan dengan kode status di luar rentang 2xx. Kode yang setara tidak memerlukan pemeriksaan status:
try {
const { data } = await axios.get('/api/user/999');
showUser(data);
} catch (err) {
showError(err); // runs on a 404
}
Perilaku Mana yang Benar
Keduanya dapat dibenarkan, dan perbedaan pendapat ini bersifat filosofis.
fetch
mengambil posisi bahwa transfer berhasil — server tercapai, server merespons, dan respons tiba utuh. Kode 404 adalah jawaban yang sah atas sebuah pertanyaan, bukan kegagalan dalam mengajukan pertanyaan tersebut. Menolak permintaan akan mencampuradukkan kegagalan transportasi dengan semantik aplikasi. Kebetulan, ini juga persis sama dengan posisi curl, di mana kode 404 juga menghasilkan kode keluar nol.
Axios berpendapat bahwa sebagian besar pemanggil menganggap kode 4xx atau 5xx sebagai kegagalan, sehingga Axios harus berperilaku seperti itu.
Kenyataannya, model fetch
lebih tepat namun lebih rentan terhadap kesalahan, karena model tersebut menuntut kedisiplinan pada setiap panggilan dan tidak ada peringatan apa pun ketika kedisiplinan tersebut dilanggar.
Apa Itu Fetch dan Berapa Biayanya
Standar ini, beserta kelebihan dan kekurangannya.
Kelebihannya
Sudah terintegrasi. Tanpa ketergantungan, tanpa instalasi, tanpa biaya paket, dan tanpa rantai pasokan yang perlu diaudit. Di peramban dan Node modern, fitur ini sudah tersedia begitu saja.
Ini adalah standar. Ditetapkan, bukan dikelola oleh suatu proyek yang mungkin berubah arah, ditinggalkan, atau memperkenalkan perubahan yang merusak (breaking change) sesuai jadwalnya sendiri.
Ini adalah fondasinya. Banyak pustaka tingkat tinggi merupakan pembungkus (wrapper) di sekelilingnya, sehingga memahami fetch berarti memahami apa yang dilakukannya.
Fitur ini menangani streaming dengan baik. Response.body adalah aliran yang dapat dibaca, yang membuat pemrosesan progresif respons berukuran besar menjadi hal yang wajar.
Apa yang Tidak Dilakukannya
Inilah celah-celah yang harus Anda isi sendiri, dan jumlahnya justru menjadi alasan sebenarnya untuk menggunakan Axios.
Tidak ada JSON otomatis. Anda memanggil .json(), yang merupakan await lain dan titik kegagalan lain jika respons bukan JSON — misalnya halaman kesalahan HTML, yang persis seperti yang Anda dapatkan dari server yang salah konfigurasi.
Tidak ada penolakan status. Telah dibahas di atas.
Tidak ada batas waktu (timeout) secara default. Panggilan fetch dapat macet tanpa batas waktu. AbortSignal.timeout() menyediakan fitur ini di lingkungan modern, tetapi fitur ini harus diaktifkan secara manual dan mudah terlupakan — yang paling penting justru dalam situasi di mana kemacetan paling parah.
Tidak ada interceptor. Tidak ada tempat untuk melampirkan token otentikasi, ID korelasi, atau pencatatan (logging) secara terpusat. Setiap panggilan harus mengulanginya atau Anda harus menulis wrapper, dan menulis wrapper adalah cara orang secara tidak sengaja membangun Axios versi mereka sendiri yang lebih buruk.
Tidak ada progres unggahan. Progres unduhan dimungkinkan melalui aliran respons; progres unggahan tidak semudah itu.
Tidak ada serialisasi isi permintaan secara otomatis. Anda memanggil JSON.stringify dan mengatur tipe kontennya sendiri, setiap kali.
Tidak ada konfigurasi proxy di Node. Ada bagian tersendiri di bawah ini.
Ringkasan Jujur
fetch adalah primitif tingkat rendah yang dirancang dengan baik. Kekurangannya disengaja — sebuah standar harus minimalis dan netral.
Pertanyaannya bukanlah apakah ini bagus. Pertanyaannya adalah apakah Anda ingin mengimplementasikan lapisan yang hilang itu sendiri, dan apakah versi yang Anda implementasikan akan lebih baik daripada versi yang dikelola oleh proyek dengan basis pengguna yang besar yang telah mengidentifikasi kasus-kasus ekstremnya.
Apa yang Ditawarkan Axios
Berdasarkan dokumentasinya sendiri, daftar fiturnya menjadi daya tarik utama.
Klien HTTP berbasis Promise dengan antarmuka yang konsisten di seluruh lingkungan, serta menyediakan paket terpisah untuk browser dan Node.
Interceptor untuk permintaan dan respons, yang merupakan fitur paling berharga sekaligus yang paling sulit untuk ditiru dengan rapi. Cukup tambahkan header otentikasi sekali, tangani refresh 401 sekali, tambahkan pencatatan (logging) sekali — dan setiap permintaan dalam aplikasi akan mewarisinya.
Penanganan JSON otomatis di kedua arah. Isi permintaan (request body) diserialisasikan dan tipe kontennya ditetapkan; respons diparsing menjadi response.data.
Penanganan kesalahan dengan penolakan pada status non-2xx.
Konfigurasi batas waktu, yang dijelaskan dalam dokumentasi sebagai pencegahan permintaan yang macet tanpa batas waktu. Satu nilai konfigurasi, bukan pengendali pembatalan (abort controller) per panggilan.
Pembatalan permintaan yang sedang diproses.
Pelacakan kemajuan untuk unggahan maupun unduhan, yang tidak ditawarkan secara langsung oleh fetch.
Perlindungan XSRF terintegrasi.
Pengiriman berkas dan data formulir multipart ditangani untuk Anda.
Pembatasan laju dan pengaturan kecepatan permintaan.
Instan dengan pengaturan default, sehingga klien yang telah dikonfigurasi dengan URL dasar, header, dan batas waktu dapat dibuat sekali dan diimpor ke mana saja.
Biaya
Ketergantungan. Sesuatu yang harus diinstal, diperbarui, dan diaudit. Dalam lingkungan yang mengutamakan keamanan, ini merupakan biaya nyata, bukan sekadar biaya teoretis.
Ukuran bundel. Berarti bagi frontend kecil, tetapi dapat diabaikan untuk aplikasi besar atau apa pun yang berada di sisi server.
Abstraksi lain yang perlu dipelajari, dan terkadang berperilaku berbeda dari platform di bawahnya dengan cara yang mengejutkan Anda.
Perspektif yang Adil
Axios pada dasarnya adalah apa yang kebanyakan orang akhirnya bangun di atas fetch ketika mereka membutuhkan perilaku-perilaku ini — kecuali Axios sudah ditulis, sudah di-debug, dan sudah menangani kasus-kasus yang belum Anda pikirkan.
Jika Anda tidak membutuhkan satupun dari fitur-fitur tersebut, maka ini hanyalah dependensi yang sia-sia.
Perbandingan
| fetch | Axios |
|---|
| Instalasi | Terintegrasi | npm install |
| Menolak pada 404/500 | Tidak | Ya |
| Parsing JSON | Manual .json() | Otomatis |
| Serialisasi badan permintaan | Manual | Otomatis |
| Timeout | AbortSignal.timeout() | Opsi konfigurasi |
| Interceptor | Tidak | Ya |
| Kemajuan unggahan | Tidak langsung | Ya |
| Kemajuan unduhan | Melalui aliran respons | Ya |
| Pembatalan | AbortController | Terintegrasi |
| Perlindungan XSRF | Manual | Terintegrasi |
| Instansi dengan nilai default | Tidak | Ya |
| Konfigurasi proxy di Node | Tidak | Ya |
| Streaming | Sangat baik | Lebih terbatas |
| Biaya bundel | Nol | Kecil tetapi tidak nol |
Permintaan yang Sama, Dua Cara
// fetch, written correctly
const res = await fetch('https://api.example.com/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${token}`
},
body: JSON.stringify({ name: 'Alice' }),
signal: AbortSignal.timeout(5000)
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
// Axios
const { data } = await axios.post(
'https://api.example.com/users',
{ name: 'Alice' },
{ headers: { Authorization: `Bearer ${token}` }, timeout: 5000 }
);
Keduanya benar. Versi fetch terdiri dari sebelas baris, sedangkan Axios hanya lima baris, dan perbedaannya sepenuhnya terdiri dari hal-hal yang harus Anda ingat pada setiap panggilan, bukan yang dikonfigurasi sekali saja.
Dua Baris yang Menentukan
Penolakan pada 404/500 dan konfigurasi proxy di Node adalah satu-satunya baris di mana satu alat tidak dapat secara langsung melakukan apa yang dilakukan alat lainnya. Sisanya adalah kode standar, dan kode standar merupakan biaya, bukan hal yang mustahil.
Biaya Boilerplate
Perbandingan yang sesungguhnya bukanlah antara satu panggilan ke fetch
dan satu panggilan ke axios
. Melainkan antara basis kode yang menggunakan masing-masing dari keduanya.
Apa yang Pada Akhirnya Ditulis oleh Semua Orang
Setelah ketiga atau keempat kalinya Anda mengulangi pemeriksaan status, batas waktu, dan penguraian JSON, Anda akan menulis ini:
async function request(url, options = {}) {
const res = await fetch(url, {
...options,
headers: {
'Content-Type': 'application/json',
...(token && { Authorization: `Bearer ${token}` }),
...options.headers
},
signal: options.signal ?? AbortSignal.timeout(options.timeout ?? 10000)
});
if (!res.ok) {
const body = await res.text();
throw new HttpError(res.status, body);
}
return res.status === 204 ? null : res.json();
}
Itu adalah pembungkus (wrapper) yang masuk akal dan cukup bagus. Itu juga, tak dapat disangkal, merupakan Axios dalam bentuk mini.
Apa yang Tidak Akan Ditangani oleh Pembungkus Sampai Seseorang Menyadarinya
Percobaan ulang dengan backoff. Pembaruan token pada status 401 tanpa terjadinya "request storm" saat beberapa panggilan gagal sekaligus. Permintaan yang mengembalikan HTML alih-alih JSON. Respons 204 tanpa isi. Pembatalan yang diteruskan melalui panggilan bersarang. Kemajuan unggahan. Tipe konten selain JSON. ID korelasi untuk pelacakan.
Masing-masing adalah penambahan kecil. Secara kolektif, semuanya merupakan sebuah pustaka, dan versi yang Anda tulis akan kurang teruji dibandingkan versi yang sudah digunakan oleh ribuan orang.
Kapan Menulisnya Sendiri Adalah Pilihan yang Tepat
Ketika Anda hanya membutuhkan sedikit saja. Beberapa permintaan GET ke satu API. Wrapper di atas terdiri dari tiga puluh baris kode dan Anda sepenuhnya mengendalikannya.
Ketika ukuran bundel benar-benar penting. Halaman yang sangat bergantung pada kinerja, di mana setiap kilobyte sangat berharga.
Ketika dependensi mahal. Lingkungan di mana setiap paket memerlukan peninjauan.
Ketika Anda ingin memahami platformnya. Alasan yang sah, dan pemahaman tersebut dapat ditransfer.
Kapan Hal Ini Tidak Tepat
Ketika Anda sudah berada pada iterasi wrapper ketiga, ketika bagian-bagian berbeda dari basis kode memiliki wrapper yang berbeda, atau ketika Anda menambahkan logika percobaan ulang. Pada titik itu, Anda sedang memelihara sebuah pustaka sebagai proyek sampingan, dan dependensi yang Anda hindari lebih murah daripada yang Anda buat sendiri.
Ukuran Bundel dan Pertanyaan tentang Node
Dua faktor kontekstual yang memengaruhi jawabannya.
Di Browser
Axios menambah beban pada bundel Anda. Apakah hal itu penting atau tidak, sepenuhnya bergantung pada apa yang sedang Anda kembangkan.
Halaman arahan atau widget di mana waktu muat adalah produknya — gunakan fetch. Setiap kilobyte itu nyata, dan pola permintaannya biasanya cukup sederhana sehingga kode boilerplate-nya tidak menjadi masalah.
Aplikasi besar yang sudah menggunakan kerangka kerja dan pustaka komponen — biaya marjinalnya tidak signifikan, dan dukungan interceptor jauh lebih berharga daripada ukuran byte-nya.
Kenyataannya, ukuran bundel adalah argumen yang sering digunakan orang ketika mereka ingin alasan teknis untuk preferensi estetika. Hal ini memang nyata, tetapi jauh lebih jarang menjadi faktor penentu daripada yang sering disebut-sebut.
Di Node
Perhitungannya sama sekali berbeda. Ukuran bundel tidak relevan di server, sehingga argumen utama yang menentang Axios menjadi tidak berlaku.
fetchasi native tersedia di Node modern dan berfungsi dengan baik. Namun, kode sisi server cenderung membutuhkan hal-hal yang justru tidak disertakan oleh fetch: batas waktu (timeout) untuk segala hal, percobaan ulang dengan penundaan (backoff), penanganan otentikasi terpusat, pencatatan terstruktur untuk panggilan keluar, dan — seperti yang dibahas pada bagian berikutnya — konfigurasi proxy.
Jadi, keseimbangan lebih condong ke Axios di sisi server daripada di browser, yang justru berlawanan dengan cara argumen tersebut biasanya disampaikan.
Kompromi yang Tak Pernah Dibicarakan
Anda bisa menggunakan keduanya. Gunakan fetch untuk panggilan sederhana, dan Axios saat Anda membutuhkan fitur-fitur lanjutan. Tidak ada yang melarang hal ini, dan argumen konsistensi sebenarnya lebih lemah daripada yang terdengar.
Yang benar-benar menimbulkan masalah adalah tiga pembungkus (wrapper) buatan sendiri yang berbeda dalam satu basis kode, yang masing-masing menangani kesalahan dengan cara yang sedikit berbeda. Hal itu lebih buruk daripada menggunakan salah satu pustaka secara konsisten, dan inilah yang terjadi pada sejumlah besar proyek.
Proxy di Keduanya
Bidang kami, sekaligus sumber sore yang benar-benar membingungkan bagi banyak pengembang.
Versi Singkat
Fungsi fetch bawaan di Node.js tidak membaca variabel lingkungan proxy standar. Menyetel HTTP_PROXY dan HTTPS_PROXY tidak akan berpengaruh apa-apa, tidak seperti curl, tidak seperti kebanyakan pustaka HTTP, dan tidak seperti yang diharapkan hampir semua orang.
fetch global Node dibangun di atas undici, dan pengalihan melalui proxy memerlukan penyediaan dispatcher secara eksplisit:
import { ProxyAgent, setGlobalDispatcher } from 'undici';
setGlobalDispatcher(new ProxyAgent('http://user:pass@proxy.example.com:8080'));
// now fetch goes through the proxy
const res = await fetch('https://example.com');
Atau per permintaan, dengan meneruskan opsi dispatcher.
Axios di Node
Axios memiliki opsi konfigurasi proxy:
const res = await axios.get('https://example.com', {
proxy: {
protocol: 'http',
host: 'proxy.example.com',
port: 8080,
auth: { username: 'user', password: 'pass' }
}
});
Untuk proxy SOCKS, atau untuk kontrol yang lebih detail, pendekatan umumnya adalah menggunakan pustaka agen yang diteruskan sebagai httpAgent dan httpsAgent.
Di Browser, Keduanya Tidak Bisa
Perlu disebutkan karena ini menghemat waktu. JavaScript di browser tidak dapat mengatur proxy. Browser menggunakan pengaturan yang telah dikonfigurasi oleh sistem atau ekstensi, dan tidak ada pustaka yang dapat mengubahnya. Opsi proxy dari Axios adalah fitur Node.
Jika Anda memerlukan permintaan yang melalui proxy dari kode berbasis browser, permintaan tersebut harus melalui server yang Anda kendalikan.
Petunjuk Debugging
Jika proxy “tidak berfungsi” di Node, periksa klien mana yang melakukan permintaan sebelum memeriksa hal lain. Kode yang berfungsi dengan Axios tetapi gagal dengan fetch — atau sebaliknya — hampir selalu disebabkan oleh hal ini, dan hal ini tidak terlihat karena keduanya tidak menampilkan kesalahan. Permintaan tersebut hanya dikirim secara langsung.
Verifikasi dengan mengirimkan permintaan ke titik akhir pelaporan alamat melalui klien yang telah Anda konfigurasi dan pastikan alamat yang dikembalikan adalah alamat proxy tersebut.
Dan Bagian yang Bertentangan dengan Kepentingan Kita Sendiri
Sebagian besar panggilan HTTP sisi server sama sekali tidak memerlukan proxy. Memanggil API yang kredensialnya Anda miliki, dari server yang diizinkan mengaksesnya, tidak memerlukan hal tambahan apa pun — proxy hanya menambah latensi, titik kegagalan, dan biaya. Proxy berperan penting untuk pemeriksaan geografis dan pengumpulan data dalam volume besar di mana batasan tarif per alamat berlaku. Di luar itu, klien biasa adalah pilihan yang lebih baik.
Mana yang Harus Dipilih
Daftar pertimbangan, bukan kesimpulan mutlak.
Gunakan fetch jika
Ukuran bundel benar-benar krusial. Halaman arahan, widget, skrip tertanam.
Permintaan Anda sederhana. Beberapa permintaan GET, penanganan kesalahan minimal, tanpa otentikasi bersama.
Anda tidak dapat menambahkan dependensi, atau setiap paket memerlukan peninjauan.
Anda bekerja dengan aliran data (streams). Model streaming fetch lebih baik, dan ini merupakan keunggulan teknis yang nyata, bukan sekadar preferensi.
Anda ingin mempelajari platform ini. Pengetahuan ini dapat ditransfer; sedangkan pengetahuan khusus Axios tidak.
Gunakan Axios jika
Anda membutuhkan interceptor. Otentikasi terpusat, penyegaran token, pencatatan, ID korelasi. Ini adalah alasan tunggal terkuat dan tidak ada padanan yang jelas di fetch.
Anda berada di sisi server. Ukuran bundel tidak menjadi masalah dan fitur-fitur yang tidak tersedia justru merupakan hal yang dibutuhkan oleh kode server.
Anda membutuhkan progres unggahan, yang tidak dapat dilakukan dengan mudah menggunakfetch.
Anda melakukan banyak permintaan yang beragam di seluruh basis kode yang besar dan menginginkan perilaku yang konsisten tanpa perlu memelihara wrapper.
Anda membutuhkan konfigurasi proxy dan lebih memilih menggunakan opsi yang terdokumentasi daripada merakit dispatcher.
Apa pun Pilihan Anda
Selalu tetapkan batas waktu (timeout). Gunakan opsi AbortSignal.timeout() atau opsi timeout dari Axios. Permintaan tanpa batas waktu dapat macet tanpa batas waktu, dan ini adalah masalah keandalan paling umum dalam kode HTTP JavaScript.
Selalu periksa status dengan fetch. Setiap panggilan, tanpa kecuali. res.ok terdiri dari dua kata, dan ketidakhadiran keduanya adalah bug yang menjadi pembuka artikel ini.
Sentralisasikan. Satu wrapper atau satu instance Axios yang dikonfigurasi. Tiga pendekatan yang tidak konsisten dalam satu basis kode lebih buruk daripada kedua pustaka tersebut, dan itu adalah hasil yang tidak akan dipilih oleh siapa pun secara sengaja.
Pertanyaan Terkait
Apa perbedaan utama antara Axios dan fetch?
Penanganan kesalahan. Menurut MDN, janji fetch "tidak akan ditolak jika server merespons dengan kode status HTTP yang menandakan kesalahan" — Anda harus memeriksa response.ok sendiri. Axios akan menolak permintaan jika kode statusnya bukan 2xx. Selebihnya adalah fitur kenyamanan: Axios menambahkan interceptor, konversi JSON otomatis, batas waktu, pemantauan kemajuan, dan konfigurasi proxy.
Apakah Axios masih diperlukan sekarang setelah fetch sudah terintegrasi?
Tergantung pada kebutuhan Anda. Untuk permintaan sederhana, tidak. Untuk interceptor, progres unggahan, pengaturan default per-instans, atau konfigurasi proxy Node, Axios masih menyediakan fitur-fitur yang tidak ada di fetch, dan menulisnya sendiri berarti harus memelihara pustaka kecil.
Mengapa fetch tidak melempar pengecualian pada kode status 404?
Karena transfer berhasil — server tercapai dan memberikan respons. fetch memperlakukan kode status 404 sebagai respons yang valid, bukan permintaan yang gagal, dan hanya menolak permintaan jika terjadi kesalahan jaringan atau URL yang tidak valid. Periksa response.ok pada setiap panggilan.
Mana yang lebih cepat, Axios atau fetch?
Untuk satu permintaan, perbedaannya dapat diabaikan; keduanya bergantung pada kecepatan jaringan. Axios menambahkan sedikit proses tambahan dan, di browser, sedikit waktu unduh untuk pustaka itu sendiri.
Bagaimana cara mengatur batas waktu (timeout) dengan fetch?
AbortSignal.timeout(5000) diserahkan sebagai opsi signal di lingkungan modern, atau AbortController dengan timer Anda sendiri. Tidak ada batas waktu default, sehingga permintaan tanpa batas waktu dapat macet tanpa batas waktu.
Apakah fetch berfungsi dengan proxy di Node?
Tidak melalui variabel lingkungan biasa. fetch global Node dibangun di atas undici dan tidak membaca HTTP_PROXY atau HTTPS_PROXY. Anda harus menyediakan dispatcher ProxyAgent, baik secara global dengan setGlobalDispatcher maupun per permintaan. Axios memiliki opsi konfigurasi proxy sebagai gantinya.
Bisakah saya menggunakan proxy dengan fetch di browser?
Tidak. JavaScript browser tidak dapat mengonfigurasi proxy — browser menggunakan pengaturan sistem atau ekstensi. Opsi proxy pada pustaka apa pun merupakan fitur khusus Node. Permintaan yang diproksi dari browser harus melalui server yang Anda kendalikan.
Apakah sebaiknya saya menggunakan Axios dan fetch dalam satu proyek?
Hal ini tidak menjadi masalah pada dasarnya. Yang menimbulkan masalah nyata adalah adanya beberapa pembungkus (wrapper) buatan sendiri yang tidak konsisten dengan perilaku kesalahan yang berbeda-beda. Konsistensi dalam penanganan kegagalan lebih penting daripada perpustakaan mana yang menghasilkan permintaan tersebut.
Kesimpulan
Satu perbedaan bersifat substantif, sedangkan sisanya hanya soal preferensi.
** Fungsi fetch tidak akan menolak permintaan jika terjadi kesalahan HTTP.** MDN menyatakan hal ini secara eksplisit: kode status 404 atau 504 akan diproses, dan Anda harus memeriksa sendiri response.ok atau response.status. Jika Anda melewatkan hal ini pada satu panggilan, kegagalan akan muncul di tempat lain yang sama sekali berbeda, berupa kesalahan yang membingungkan terkait data yang sebenarnya tidak pernah valid. Axios secara default akan menolak permintaan dengan kode status selain 2xx. Kedua pendekatan ini dapat dibenarkan; hanya satu yang memerlukan kedisiplinan pada setiap panggilan, dan kedisiplinan bukanlah sifat yang dapat dipertahankan oleh basis kode di bawah tekanan tenggat waktu.
Selebihnya bergantung pada apa yang sedang Anda bangun. Di browser, fetch sudah terintegrasi dan gratis, dan untuk pola permintaan sederhana, kode boilerplate-nya sangat sederhana. Di server, ukuran bundle tidak lagi menjadi masalah, dan fitur-fitur yang dihilangkan oleh fetch — timeout, interceptor, retry, konfigurasi proxy — justru merupakan hal yang dibutuhkan oleh kode server, sehingga keseimbangan bergeser ke arah lain.
Uji coba yang layak dilakukan: jika Anda telah menulis pembungkus (wrapper) di sekitar fetch dan kini panjangnya melebihi sekitar tiga puluh baris, Anda sedang memelihara perpustakaan HTTP kecil. Itu adalah pilihan yang sah jika dilakukan dengan sengaja, dan pilihan yang buruk jika dilakukan secara tidak sengaja.
Mengenai proxy, dan inilah bagian yang membuat orang menghabiskan waktu berjam-jam: fetch bawaan di Node mengabaikan variabel lingkungan proxy standar. Menyetel HTTPS_PROXY tidak berbuat apa-apa, permintaan tetap langsung, dan tidak ada kesalahan yang muncul. Gunakan dispatcher ProxyAgent yang tidak ditentukan, atau gunakan opsi proxy dari Axios — dan verifikasi melalui endpoint pelaporan alamat daripada mengasumsikannya.
Kami menjual proxy, dan sebagian besar permintaan sisi server tidak membutuhkannya. Jika Anda memang membutuhkannya, mengetahui klien mana yang Anda gunakan adalah langkah debugging pertama, bukan yang terakhir.
