A React codebase fetches everything with `useEffect` plus `fetch`. How do you decide whether to move that onto a caching data layer or onto server-side fetching, and when is fetching in an effect still the right answer?

## Decide from symptoms, not from fashion "Fetching in effects is outdated" is not an argument, and an interviewer will push on it. The defensible version enumerates the concrete costs and checks which ones this codebase is actually paying. The symptom list is the leaf's own failure list, turned into evidence you can look for: - **Duplicate requests.** Several components or screens read the same resource, and the network panel shows it fetched repeatedly, including on every back-navigation. - **Freshness rules reinvented per screen.** Someone has already written "refetch on focus" or "poll every 30 seconds" by hand, in more than one place, slightly differently. - **Post-mutation staleness.** After a save, some other part of the UI keeps showing the old value until a remount. - **Waterfalls on the critical path.** Nested effect fetches serialise round trips before the first meaningful paint. - **Empty server HTML.** The content must be indexable, must generate a link preview, or is the LCP element, and it is not in the markup. - **Loading and error boilerplate.** The same five branches copy-pasted across dozens of components, inconsistently. If you find one or two of these on a small app, fix them in place. If you find most of them, you are already maintaining a bad data layer — the choice is whether to keep writing it yourself. ## The two alternatives solve different problems This is the distinction most candidates blur. **A caching data layer** keeps fetching on the client and adds identity, dedupe, reuse across mounts, invalidation, retry and a status machine. It attacks duplication, staleness and boilerplate. It does *not* remove the round trip, and it does not put anything in the server HTML. **Server-side fetching** — a server component that awaits during render, or a route loader that resolves before render — attacks latency, waterfalls and empty initial HTML by moving the request next to the data. It does not, on its own, give you client-side revalidation or optimistic updates for data that keeps changing while the user sits on the page. So an app whose problem is "three widgets fetch the same profile and drift apart" needs the cache. An app whose problem is "the article body is not in the HTML and the page takes three round trips to become useful" needs server-side fetching. Many real apps need both, with server-rendered initial data and a client cache for the parts that mutate. ## When effects are still right Be explicit that the answer is not "never", or the position sounds dogmatic: - Data used by exactly one component, fetched once, never shared. - Content behind an interaction that is not indexable and not on the critical path. - Data that depends on browser-only state and cannot exist on the server. - An admin tool, an internal dashboard, or a prototype where a dependency and its concepts cost more than the boilerplate saves. A small app with three screens does not need a caching layer, and adding one there is a real cost: another mental model for every contributor, another upgrade path, another set of subtle behaviours to learn. ## Sequencing the migration The most senior part of the answer is usually the transition, not the destination. - **Migrate by resource, not by file.** Move every reader of one entity at once, so that entity never has two sources of truth. Half-migrated entities produce exactly the inconsistency you set out to remove. - **Start where the pain is measurable** — the screen with the duplicate requests, or the route whose LCP is failing — so the first increment justifies the rest. - **Stop the bleeding first.** Agree that new code uses the target model even before old code moves; otherwise the migration never converges. - **Set a deletion deadline for the old path.** Keeping both indefinitely is the failure mode: every contributor then has to learn two data models and decide between them. - **Watch the bundle and the boundary.** A client cache is client bytes; server-side fetching moves work into infrastructure you now have to operate and observe. Neither is free. ## What to measure afterwards Commit to evidence: requests per page load, time to first meaningful content on a throttled connection, the count of hand-written loading branches removed, and post-mutation staleness bugs reported. If none of those move, the migration was taste, not engineering — and being willing to say so is what distinguishes a judgment answer from a preference.