Belajar TanStack Query - Security & Best Practice

#Pendahuluan

Cache yang menyimpan data server adalah pedang bermata dua: di satu sisi mempercepat aplikasi, di sisi lain menyimpan data yang bisa bocor jika tidak dikelola dengan hati-hati. Memikirkan keamanan setelah aplikasi besar bukanlah pilihan — dasar-dasarnya harus tertanam sejak awal.

Episode 15 membahas keamanan dari sudut TanStack Query: cara menangani 401 dan 403, aturan data sensitif di cache, sanitasi error, lalu best practice struktur kode yang menjaga project tetap sehat.

#Menangani 401 dan 403

#Pola Refetch Token

Ketika token akses kedaluwarsa, server mengembalikan 401. Pola umum: refresh token otomatis, lalu ulangi permintaan. TanStack Query tidak menyediakan interceptor seperti axios, jadi handle di queryFn atau di lapisan API:

Menangani 401 di queryFn

async function authedFetch(url) {
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${getAccessToken()}` },
  })
 
  if (res.status === 401) {
    const refreshed = await tryRefreshToken()
    if (refreshed) {
      return authedFetch(url)
    }
    redirectToLogin()
    throw new Error("Sesi berakhir")
  }
  if (res.status === 403) {
    throw new Error("Akses ditolak")
  }
  return res.json()
}

Saat res.status === 401, fungsi mencoba refresh token lalu mengulang request sekali. Jika refresh gagal, user diarahkan ke login. authedFetch mengkonsolidasikan logika autentikasi sehingga semua queryFn memakai satu jalur yang aman.

#Mendistribusikan ke Semua Query

Daripada menulis ulang logika 401 di setiap queryFn, jadikan authedFetch pembungkus standar semua panggilan API:

Query memakai authedFetch

const { data } = useQuery({
  queryKey: ["todos"],
  queryFn: () => authedFetch("/todos"),
})

authedFetch("/todos") memberi semua query penanganan 401 yang konsisten. Kesalahan umum: menangani 401 di beberapa tempat dengan perilaku yang berbeda, sehingga sesi kedaluwarsa menampilkan error acak di tiap halaman.

#403 untuk Authorization

403 berarti pengguna valid tapi tidak berhak. Tangani berbeda dari 401 — tidak ada gunanya refresh token. Tampilkan pesan "akses ditolak" dan jangan meng-cache respons 403.

#Data dan Cache

#Menghindari Data Sensitif Berlebihan

Cache TanStack Query hidup di memori, dan jika dipersist (episode 12) akan tersimpan di localStorage yang bisa dibaca skrip di origin yang sama. Aturan sederhana:

• Jangan simpan token atau kredensial di cache.
• Jangan persist data pribadi yang tidak perlu di localStorage.
• Gunakan gcTime yang pendek untuk data sensitif.
• Batasi cakupan query data pribadi per user agar tidak bocor antar sesi.

#Sanitasi Error

Objek error yang dilempar queryFn bisa saja berisi detail internal yang tidak layak ditampilkan. Jangan pernah menampilkan error.message dari server langsung ke UI:

Sanitasi pesan error

function getUserFacingMessage(error) {
  if (error instanceof AuthError) return "Sesi berakhir, silakan masuk lagi"
  if (error instanceof ApiError) return "Terjadi kesalahan, coba lagi nanti"
  return "Kesalahan tak terduga"
}

getUserFacingMessage memetakan tipe error ke pesan yang aman untuk user. Jangan menampilkan stack trace atau detail response mentah ke UI — simpan detail teknis di log yang hanya diakses developer.

#Best Practice Struktur

#Query Key Convention

Dari episode 5, konsistensi query key adalah kunci. Tetapkan konvensi di awal:

["todos", "list", { filter }]
["todos", "detail", id]
["users", id, "posts"]

Konvensi ["todos", "list", { filter }] menetapkan pola domain → resource → modifikasi. Konvensi yang konsisten membuat invalidasi mudah dinalar dan mencegah key duplikat yang diam-diam membaca cache salah.

#Pemisahan Server State vs Client State

Ini prinsip paling penting dari seluruh series: TanStack Query untuk server state, bukan client state. UI state seperti modal terbuka, tab aktif, theme, atau isi draft form adalah client state — simpan di useState, Zustand, atau Redux. Mencampur keduanya membuat cache menampung data yang sebenarnya bukan tanggung jawabnya.

TanStack Query → data dari server (todos, users, profil)
Zustand/Redux  → UI state (modal, theme, keranjang, filter sementara)

Pembagian TanStack Query → data dari server dan Zustand/Redux → UI state menghindari duplikasi dan kebingungan. Episode 16 akan membahas pola hybrid ini lebih dalam.

#Penutup

Episode 15 membekali kalian praktik keamanan dan struktur: penanganan 401 dan 403 yang konsisten, aturan data sensitif di cache, sanitasi error untuk user, serta best practice query key dan pemisahan server state dari client state.

Inti yang harus dibawa pulang:

• Tangani 401 dengan refresh token dan ulangi request sekali.
• 403 berarti tidak berhak — tampilkan pesan ditolak.
• Jangan simpan token dan data pribadi berlebih di cache.
• Sanitasi pesan error sebelum ditampilkan ke user.
• Tetapkan konvensi query key di awal project.
• TanStack Query untuk server state; Zustand atau Redux untuk UI state.

Di episode 16 selanjutnya kita akan membahas integrasi dengan state management — pola hybrid TanStack Query untuk server state dengan Zustand atau Redux untuk UI state, serta memperlakukan cache sebagai single source of truth dengan getQueryData.