Belajar TanStack Query - Ekosistem Alternatif & Refleksi Akhir

#Pendahuluan

Setiap episode di series ini membandingkan TanStack Query dengan pendekatan lain, tapi belum pernah menelaah peta lengkapnya. Episode terakhir ini menyajikan peta tersebut: SWR, RTK Query, Apollo GraphQL, dan useEffect manual. Kalian akan melihat kekuatan dan kelemahan masing-masing, lalu memutuskan kapan memilih yang mana.

Episode 22 juga menutup perjalanan kalian. Setelah perbandingan, kita rekap seluruh journey dari episode 0 sampai 21, merangkum stack server state produksi 2026, dan melihat arah evolusi TanStack Query: TanStack Start dan Query v6. Ini bukan akhir dari belajar, melainkan fondasi untuk membangun aplikasi sungguhan.

#TanStack Query vs SWR

SWR adalah pustaka data fetching dari Vercel dengan filosofi "stale-while-revalidate": tampilkan data lama secepat mungkin, lalu revalidate di latar belakang. Konsep ini nyaris sama dengan TanStack Query, tapi dengan cakupan fitur yang lebih ramping. Pasang ketiganya di project eksperimen kalian untuk membandingkan langsung:

npm i swr
npm i @reduxjs/toolkit
npm i @apollo/client graphql

Fetching dengan SWR

import useSWR from "swr"
 
const fetcher = (url) => fetch(url).then((res) => res.json())
 
function Todos() {
  const { data, isLoading, error } = useSWR("/api/todos", fetcher)
  return <p>Jumlah todos: {data ? data.length : 0}</p>
}

useSWR membuat hook tanpa queryFn terpisah — fetcher dipanggil dengan key sebagai argumen. Untuk aplikasi kecil yang butuh caching sederhana, SWR adalah pilihan sah yang mudah dipelajari. Namun ketika kebutuhan tumbuh — mutations dengan optimistic update, dependent queries, infinite queries, persistence, devtools — TanStack Query menang dengan fitur yang lebih lengkap dan terkelola di satu ekosistem.

Perbedaan praktis yang terasa: TanStack Query punya useMutation kelas satu dengan lifecycle onMutate, onError, dan onSettled; SWR menyerahkan operasi tulis ke kode manual. Infinite queries di TanStack Query memiliki getNextPageParam dan fetchNextPage yang teruji; SWR memakai pola useSWRInfinite yang lebih sederhana tapi kurang kaya. Untuk tim yang serius membangun aplikasi data-heavy, fitur ini sering menjadi pembeda.

#RTK Query dan Apollo

#RTK Query untuk Ekosistem Redux

RTK Query terintegrasi langsung dengan Redux Toolkit: cache-nya hidup di dalam store Redux, dan endpoint dideskripsikan di createApi. Kekuatannya adalah akses ke Redux DevTools dan satu tempat untuk seluruh state — tidak ada paradigma kedua yang harus dipelajari tim.

Endpoint di RTK Query

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react"
 
export const todosApi = createApi({
  reducerPath: "todosApi",
  baseQuery: fetchBaseQuery({ baseUrl: "https://jsonplaceholder.typicode.com" }),
  endpoints: (builder) => ({
    getTodos: builder.query({ query: () => "/todos" }),
  }),
})
 
export const { useGetTodosQuery } = todosApi

Kelemahan RTK Query: data server dan client state tercampur di store yang sama, dan API-nya lebih verbosa daripada hooks TanStack Query. createApi mengharuskan mendeskripsikan endpoint dalam satu entitas besar, sementara TanStack Query memberi kebebasan menyusun query per domain. Pilih RTK Query jika kalian sudah berkomitmen penuh pada Redux dan tidak ingin menambah paradigma kedua.

#Apollo untuk GraphQL

Apollo Client adalah pilihan dominan untuk aplikasi GraphQL. Ia menyediakan cache normalisasi berbasis tipe, schema-aware query, dan fragment colocation yang tidak ada padanan langsungnya di TanStack Query. TanStack Query justru bekerja dengan REST atau endpoint apa pun yang mengembalikan Promise.

Untuk REST API, TanStack Query lebih ringan dan lebih fleksibel — tidak ada schema, tidak ada codegen, cukup query key dan query function. Untuk GraphQL kompleks dengan normalisasi tipe dan banyak fragment, Apollo adalah pilihan yang tepat. Ada juga jalur hibrida: memakai TanStack Query untuk REST dan Apollo untuk GraphQL di aplikasi yang sama, meski idealnya disederhanakan agar tidak double cache.

#useEffect Manual: Kapan Masih Relevan

Pola useEffect plus fetch manual — yang menjadi titik awal series ini — bukan tanpa tempat. Ia masih relevan dalam skenario:

• Data di-fetch sekali saat aplikasi dimuat dan tidak pernah berubah.
• Aplikasi tanpa kebutuhan cache, retry, atau sinkronisasi antar komponen.
• Prototype yang harus dikirim cepat dan tidak akan hidup lebih dari seminggu.

Namun begitu data bersifat shared, mutable, atau dibaca ulang, biaya manualnya membengkak: loading state berulang di setiap komponen, tanpa deduplication, tanpa retry, tanpa invalidasi. Kode yang tampak sederhana itu berubah menjadi rangkaian useEffect yang sulit dibaca dan rawan race condition. Perbandingan inilah alasan utama TanStack Query ada — semua biaya tersebut justru dihilangkan dengan otomatis.

#Kapan Memilih Masing-masing

Berikut keputusan praktis yang bisa kalian jadikan pegangan saat memulai project baru:

• Pilih TanStack Query untuk aplikasi REST/API apa pun yang datanya dibaca ulang, di-cache, atau disinkronkan — mayoritas aplikasi web modern.
• Pilih SWR untuk project kecil, prototype Vercel, atau saat kalian hanya butuh caching revalidation yang sederhana.
• Pilih RTK Query jika seluruh aplikasi sudah memakai Redux Toolkit dan kalian ingin satu store untuk segalanya.
• Pilih Apollo untuk GraphQL production-grade dengan normalisasi tipe dan fragment.
• Pilih useEffect manual untuk data sekali muat, server-rendered statis, atau eksperimen yang dibuang cepat.

Aturan terpenting: jangan gabungkan beberapa solusi data fetching tanpa alasan. Dua cache berbeda berarti dua sumber kebenaran yang bisa saling tidak sinkron. Konsisten dengan satu pustaka, dan tinggalkan jalan keluar untuk migrasi jika kebutuhan berubah.

#Rekap Journey Episode 0 sampai 21

Mari tarik garis besar perjalanan kalian. Episode 0 sampai 2 membangun fondasi: setup environment, sejarah, dan arsitektur query di atas cache global. Episode 3 sampai 7 membahas operasi inti: QueryClient, useQuery, query keys, mutations, dan aturan staleness. Episode 8 sampai 12 naik ke workload nyata: parallel dan dependent queries, pagination dan infinite queries, prefetching, optimistic updates, serta persistence offline.

Episode 13 sampai 15 menyentuh performa, SSR, dan keamanan: cache tuning, Suspense, hydrasi Next.js, dan pola penanganan 401/403. Episode 16 sampai 18 menjaga kualitas kode: integrasi dengan state management, devtools, dan testing. Episode 19 sampai 21 melengkapi: framework adapters, fitur terbaru v5, dan arsitektur produksi. Di titik ini, kalian telah memegang seluruh peta server state.

Praktik terbaik yang paling sering menyelamatkan produksi: query keys hierarkis dan terpusat, staleTime yang disetel secara sadar, invalidasi yang cermat, dan pemisahan server state dari client state. Jika kalian membawa empat hal ini ke project berikutnya, sebagian besar bug cache yang umum di lapangan tidak akan pernah menyentuh kode kalian.

#Arah Evolusi: TanStack Start dan v6

Ekosistem terus bergerak. TanStack Start — full-stack framework dari tim yang sama — membawa data fetching, routing, dan server functions ke satu tempat dengan TanStack Query sebagai bagian alaminya. Server functions yang ditulis di satu file bisa dipanggil dari client tanpa HTTP endpoint manual, dan TanStack Query menjaga konsistensi cache di sekitarnya.

Sementara itu, Query v6 sedang dikembangkan dan mulai tampil sebagai rilis beta di ekosistem Solid. Rilis beta ini memberi gambaran API generasi berikutnya tanpa mengubah perilaku stabil v5. Keduanya menunjukkan arah: server state akan semakin menyatu dengan framework, tanpa mengorbankan filosofi query keys dan cache yang sudah kalian kuasai dari episode 0 sampai 21.

#Penutup

Episode 22 adalah peta lengkap sekaligus penutup. Kalian kini bisa membandingkan TanStack Query dengan SWR, RTK Query, Apollo, dan useEffect manual, memilih yang sesuai kebutuhan, dan menempatkan TanStack Query di posisinya: pustaka server state yang matang untuk aplikasi yang tumbuh.

Inti yang harus dibawa pulang:

• SWR unggul untuk kebutuhan sederhana; TanStack Query unggul untuk fitur lengkap.
• RTK Query cocok jika sudah berkomitmen penuh pada Redux.
• Apollo adalah pilihan untuk GraphQL dengan normalisasi tipe.
• useEffect manual masih relevan untuk data sekali muat dan prototype.
• Jangan gabungkan dua solusi data fetching tanpa alasan kuat.
• Stack produksi 2026: TanStack Query untuk server state plus client state ringan.
• TanStack Start dan Query v6 adalah arah evolusi berikutnya.

Demikian perjalanan Belajar TanStack Query dari episode 0 sampai 22 berakhir. Series ini menutup rangkaian materi server state di blog ini — dari pola manual hingga arsitektur production-ready. Seluruh materi yang kalian pelajari sekarang siap diterapkan di project kalian masing-masing. Ringkasan lengkap series ini bisa kalian temukan di halaman meta series sebagai peta referensi. Terima kasih sudah menyelesaikan dua puluh tiga episode; terus berkarya dan selamat menulis aplikasi yang datanya selalu sinkron.