How does Next.js differ from React in terms of data fetching?

React and Next.js are about different levels of an application, and because of that the approach to data fetching differs a lot.

#What React has

React by itself does not provide "built-in" ways to do data fetching at the framework level. It is a UI library, so data is usually fetched like this:

• browser requests: fetch/axios inside useEffect
• libraries for requests and caching: SWR, React Query
• loading/error state is handled manually (or through those libraries)
• if server rendering or static generation is needed - that's already separate infrastructure (for example, setting up SSR yourself via Node/Express, etc.)

Bottom line in React: most often data is loaded after the first render in the browser, and questions of SEO, SSR/SSG, and "server-side" caching are not solved by React out of the box.

---

#What Next.js adds on top of React

Next.js is a framework around React that adds a server layer and rules for when and where data can be fetched.

#1) You can fetch data on the server, not only in the browser

In Next.js you can load data:

• on the server at request time (the page already arrives at the user with data)
• at build time (the page is static)
• with periodic updates (ISR)
• in Server Components (in the App Router - right inside the component)

This changes UX and SEO: the user gets HTML that already has data, instead of "an empty page + a spinner while useEffect goes off to the API".

---

#2) There are built-in strategies: SSR / SSG / ISR

In plain React you only choose "client requests" (unless you build SSR yourself). In Next.js you choose a strategy for the data:

• SSR - always fresh data
• SSG - maximum speed (data at build time)
• ISR - a balance (static + updates)
• Client fetching - when needed

This is not just "where to write fetch", but "how the page will work as a whole".

---

#3) Cache and revalidation are part of the platform

In Next.js (especially the App Router) there is built-in request caching logic and a "refresh data" mechanism (revalidate) at the server/render level.

In React, caching is usually solved:

• manually (state + effects)
• through SWR/React Query
• through external CDNs/proxies, but that's already infrastructure

---

#4) You can hide secrets and access a database safely

In React, if you make requests from the browser, then:

• API keys cannot be stored in the code
• direct database access is impossible (and unsafe)
• a separate backend is often needed

In Next.js you can:

• make requests on the server (Server Components/SSR/Route Handlers)
• use private keys and database access without sending that to the client
• build API routes / Route Handlers right in the project

---

#5) Less "movement" on the client - less JS in the browser

If data is loaded on the server, then:

• less code ends up in the bundle
• faster first meaningful render
• sometimes you can do without useEffect entirely

In plain React, everything is often tied to client rendering and subsequent requests.

---

#A simple example of "feeling the difference"

React (typical):

1. the browser gets a rather empty UI
2. useEffect makes a request
3. we show a loader -> then the data

Next.js (server variant):

1. the server makes the request
2. the browser gets HTML that already has data
3. a loader may not be needed at all (or it will be minimal)

---

#Short summary

• React: data fetching is most often on the client; SSR/SSG/ISR are not built in, external solutions are needed.
• Next.js: provides server rendering, static generation, static updates, Server Components, and API routes, that is, it controls when/where data loads, is cached, and is refreshed.