2023-09-08
2240
#nextjs
Yomi Eluwande
94059
Sep 8, 2023 ⋅ 8 min read

Data fetching in Next.js with getServerSideProps and getStaticProps

Yomi Eluwande JavaScript developer. Wannabe designer and Chief Procrastinator at Selar.co and worklogs.co.

Recent posts:

You're doing vibe coding wrong: Here's how to do it right. A LogRocket article

You’re doing vibe coding wrong: Here’s how to do it right

Vibe coding isn’t just AI-assisted chaos. Here’s how to avoid insecure, unreadable code and turn your “vibes” into real developer productivity.

Chizaram Ken
Oct 28, 2025 ⋅ 11 min read

Exploring spec-driven development with the new GitHub Spec Kit

GitHub SpecKit brings structure to AI-assisted coding with a spec-driven workflow. Learn how to build a consistent, React-based project guided by clear specs and plans.

Emmanuel John
Oct 28, 2025 ⋅ 7 min read

The different ways to use CSS :has(), with examples

The CSS :has() pseudo-class is a powerful new feature that lets you style parents, siblings, and more – writing cleaner, more dynamic CSS with less JavaScript.

Daniel Schwarz
Oct 24, 2025 ⋅ 7 min read

Kombai AI: The AI agent built for frontend development

Kombai AI converts Figma designs into clean, responsive frontend code. It helps developers build production-ready UIs faster while keeping design accuracy and code quality intact.

Jude Miracle
Oct 23, 2025 ⋅ 7 min read
View all posts

6 Replies to "Data fetching in Next.js with <code>getServerSideProps</code> and <code>getStaticProps</code>"

  1. I like the article
    have one question how we can make api call in _app.js to get the data and pass over nav component

    1. is this api call to a third party api or to one of the endpoints from the next app? Generally, unless the change is happening after the particular page loads (like data that relies on user input before making api call) I would just use getSeverSideProps or getStaticProps to make database calls instead of calling API endpoints.

  2. This is an older post, but I feel like Vercel/Next.js have done a pretty admirable job obscuring the valid reasons to still use getInitialProps. Even a lot of seasoned devs may not be aware that the original workflow most people used in earlier isomorphic/universal react apps pretty much assumed you had a separate and decoupled API. Its endpoints would be called from both client (navigation changes) and server (initial load or full browser refresh) using the same code via something like isomorphic fetch or axios.

    There are both advantages and disadvantages to this pattern:

    1. Your backend isn’t limited to Javascript/Typescript, it can be any language. Being decoupled, it’s easier when you have frontend/backend specialists.

    2. If you have a mobile app, IoT or anything else besides a web browser a decoupled API is going to save a lot of time. These things don’t share a view layer but probably do share a data source.

    While you can of course call a decoupled API endpoint in getServersideProps, it’s probably a bad idea because it adds an extra network hop when called from the client. Using the older pattern (getInitialProps in Next), you would be calling the final endpoint directly instead of “asking” the Next.js backend to do it.

    3. getServersideProps as far as I know results in more requests to your server. getInitialProps can be cached, but from the documentation it seems that GSSP is always called on route changes even when the data was recently received and still valid.

    The disadvantages are pretty well documented, but mostly avoidable if you know what you’re doing, (don’t import server only packages from isomorphic code, check for client when using browser APIs, etc).

    This is not a recommendation to use getInitialProps. It is cleaner and easier to use the newer patterns for a lot of apps. They reduce complexities, but they also introduce others. There are plenty of people who will probably just choose a different framework now that Next doesn’t seem to want to support their use case.

    These are experimental times for SSR/SPA fusion… IMO the newest patterns of islands and server components are an actual reason to be excited. It’s a bit of a mess ATM, but it will be interesting to see what it looks like once the dust settles.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now