What Data Fetching Libraries Actually Solve

The plain-language idea

A React-style data-fetching library (the React Query/SWR family of tools — described here generically, not tied to one library's current API) exists to solve a specific, mechanical set of problems that a hand-rolled useEffect + fetch + useState pattern doesn't handle for free:

• Request deduplication — if two components mount near-simultaneously and both ask for the same data, only one network request actually fires; the second consumer gets the same in-flight promise instead of triggering a duplicate request.
• Shared caching by key — data fetched by one component, keyed by something like the resource's identifier, is available to any other component asking for that same key, instead of every component independently fetching and independently going stale.
• Background refetching — data is automatically refreshed when the window regains focus or the network reconnects, so a tab left open all afternoon doesn't keep showing morning-stale data without a manual poll.
• Retry with backoff — a failed request is retried a few times with increasing delay before it's treated as a real failure, absorbing transient blips instead of surfacing every flaky request as a hard error.

See it in a real thing: two components wanting the same data

// Hand-rolled: two components, same endpoint, no coordination
function ProfileCard({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  useEffect(() => {
    fetch(`/api/users/${userId}`).then((r) => r.json()).then(setUser);
  }, [userId]);
  // ...
}

function ProfileSidebar({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  useEffect(() => {
    fetch(`/api/users/${userId}`).then((r) => r.json()).then(setUser);
  }, [userId]);
  // ...
}

If ProfileCard and ProfileSidebar both render for the same userId on the same page, this fires two independent network requests for identical data, and each keeps its own copy — if one refetches later, the other silently goes stale relative to it. A fetching library replaces this with a hook keyed on ["user", userId]: both components subscribing to that key share one in-flight request and one cached result, and a refetch from either place updates both.

What people usually miss

Watch out

• This isn't about state management — a data-fetching library is solving caching, deduplication, and freshness for data that lives on a server, which is a different problem from the client-side application state that a state management library manages. Confusing the two leads to trying to make one tool do both jobs poorly.
• Deduplication only helps if requests actually share a cache key. Two components fetching "the same data" via two differently-shaped requests (different query params, different endpoints) won't dedupe — the key has to genuinely represent the same resource.
• Hand-rolled fetching isn't always wrong. A single, one-off fetch in a small app with no shared consumers doesn't need this machinery — the point of understanding what the library solves is being able to deliberately decide it's not needed yet, not treating the library as mandatory by default.
• Background refetching can surprise you if you don't expect it. A component re-fetching on window refocus is a feature, not a bug, but it means "the data on screen might change out from under a mid-interaction user" is now a real case to design for (e.g. a half-filled form bound to fetched data).

Why this matters in interviews

"Why would you reach for a data-fetching library instead of useEffect and fetch?" is a real, common question, and naming deduplication, shared caching by key, and background refetching specifically — rather than a vague "it's easier" — is what shows the interviewer you understand the actual problem being solved, not just the tool's name.