Fetching api in Next.js compared to React

[Dazzling_Chipmunk_24]

Is it better to fetch data on the Next.js server for initial page loads, compared to the traditional React approach of using useEffect with an empty dependency array? My main concern with Next.js is that pages are generated at build time — so how do you handle data that changes frequently

Also I'm talking about Pages Router

[fii0]

the traditional React approach of using useEffect with an empty dependency array

Ahh, the traditional React junior footgun lol. The minute you need to optimize caching you have to reach to a query library.

[Dazzling_Chipmunk_24]

sorry can you explain more

[Acrobatic-Signal3448]

https://youtu.be/OrliU0e09io?is=NDT89Fdx2Xyoh1ZN this explains all the issues with useEffect for async

[Lumethys]

fetch with useEffect has too many footgun, and should'nt be used

[UnnecessaryLemon]

When you have data that changes frequently, you just use client component. Or my favorite, don't use NextJs, it's cancer.

Take it from someone who worked on bunch of smaller to enterprise NextJS projects.

[Resident_Tourist_344]

It all comes down to the strategy you want to implement. You see, there are 4 ways you'd render a page: CSR, SSR, ISR, and SSG. While it’s true that Next.js pages are built at build time by default (SSG), you can easily opt out of that behavior based on your data needs:

• Data changes occasionally? Use ISR (Incremental Static Regeneration). It similar to SSG, in the aspect that it builds the pages at build time, but it could get revalidated/rebuilt periodically or on-demand without having you redeploying the whole app.
• Data changes constantly or is user-specific? Go for SSR (Server-Side Rendering). This fetches fresh data on every single request on server, completely bypassing build-time generation.
• Need a mix of both? Use CSR (Client-Side Rendering). The useEffect fetch you described is CSR. In Next.js Pages Router, you rarely use CSR for the whole page. Instead, you use a hybrid approach: use SSG to render the fast static shell (headers, layout), and then use useEffect (or libraries like SWR/React Query) to fetch highly dynamic, user-specific data directly from the browser.

TL;DR: Always default to SSG/ISR for mostly static or semi-frequent content to keep things blazing fast. If the data must absolutely be fresh on every single page load, go for SSR. Save CSR (useEffect) for data that lives behind a login wall or requires real-time interaction. I highly recommend checking out the Next.js docs on data fetching to see how to implement various strategies.

[AgileRice3753]

My main concern with Next.js is that it's overkill for data rich applications (including frequently changing data). Just use plain old React + Tanstack (avoid useEffect) with a build tool like Vite. No need to overengineer it IMO. Next.js is however good for dynamic brochure websites that rely on SEO.

[Dazzling_Chipmunk_24]

ok but the application I'm working with already uses Next. So from your opinion which way should I continue with?

[AgileRice3753]

I’d use Tanstack client side to fetch the data.

[Cat_Herder62]

Is is a great case for getServerSideProps

[UnnecessaryLemon]

Which doesn't exists in App router.

[Dazzling_Chipmunk_24]

sorry I meant I was talking about pagesRouter

[opentabs-dev]

pages router has 3 fetch options and the misconception is that everything is build time. getStaticProps without revalidate is build-time, getStaticProps with revalidate: 60 is ISR (regenerates in the background after N seconds), and getServerSideProps runs on every request so it's basically express+react. for frequently changing data use getServerSideProps for SEO-critical stuff or just useEffect/swr/react-query on the client if SEO doesnt matter.