Pages Router Data Fetching (getStaticProps, getServerSideProps & getStaticPaths)
5 questions found
What does getStaticProps do in the Next.js Pages Router?
Beginner
getStaticProps is a special function you export from a page file that runs at build time, fetching data and passing it to your page component as props, allowing Next.js to generate a fully static HTML page ahead of time for fast loading and better SEO.
// pages/blog.js
export async function getStaticProps() {
const posts = await getPosts();
return { props: { posts } };
}
export default function Blog({ posts }) {
return <ul>{posts.map(p => <li key={p.id}>{p.title}</li>)}</ul>;
}
Real-world example
A company blog uses getStaticProps to fetch all its articles at build time, generating a fast, fully static blog listing page that loads instantly for every visitor.
Common follow-ups: When does getStaticProps actually run, during build or on each request?;How do you add a revalidate option to getStaticProps?
Rendering (SSR/SSG/ISR);Caching
What does getServerSideProps do, and how is it different from getStaticProps?
Beginner
getServerSideProps runs on every single request rather than at build time, fetching fresh data each time a user visits the page, which is useful for content that changes frequently or needs to be personalized based on the specific request, unlike getStaticProps which only runs once during the build.
// pages/profile.js
export async function getServerSideProps(context) {
const user = await getUserFromSession(context.req);
return { props: { user } };
}
export default function Profile({ user }) {
return <h1>Welcome, {user.name}</h1>;
}
Real-world example
A personalized account page uses getServerSideProps to fetch the currently logged in user's specific data fresh on every visit, since this content cannot be pre-built ahead of time for every possible user.
Common follow-ups: Does using getServerSideProps make a page slower than one using getStaticProps?;Can you access cookies and headers inside getServerSideProps?
Rendering (SSR/SSG/ISR);Cookies & Session Management in Next.js
How does getStaticPaths work together with getStaticProps for dynamic routes in the Pages Router?
Intermediate
getStaticPaths tells Next.js which dynamic route parameter values should be pre-built into static pages at build time, returning a list of paths, while getStaticProps then runs separately for each of those paths to fetch the actual data needed to render that specific page.
// pages/products/[id].js
export async function getStaticPaths() {
const products = await getAllProducts();
const paths = products.map(p => ({ params: { id: p.id.toString() } }));
return { paths, fallback: false };
}
export async function getStaticProps({ params }) {
const product = await getProduct(params.id);
return { props: { product } };
}
Real-world example
An online catalog uses getStaticPaths to list every product id that should be pre-built at build time, with getStaticProps then fetching the specific details for each of those individual product pages.
Common follow-ups: What does the fallback option in getStaticPaths actually control?;What happens when a user visits a path not included in getStaticPaths?
Dynamic Routes & Catch-All Segments;Rendering (SSR/SSG/ISR)
What are the different fallback options available in getStaticPaths, and how do they behave differently?
Intermediate
Setting fallback to false means any path not listed results in a 404 page, setting it to true shows a fallback loading state while generating the page on the first request and caching it afterward, and setting it to blocking waits to render the full page on the server before responding, without showing any fallback state at all.
export async function getStaticPaths() {
return {
paths: [{ params: { id: '1' } }],
fallback: 'blocking'
};
}
Real-world example
A large marketplace with millions of listings uses fallback blocking so new product pages generate fully on their first visit without showing a jarring incomplete loading state to the very first visitor.
Common follow-ups: Which fallback option is best for a site with an extremely large number of pages?;How does fallback true handle showing a loading state on the client?
Rendering (SSR/SSG/ISR);Loading UI & Streaming with Suspense
If you are migrating a page from getStaticProps to the App Router, how do the equivalent data fetching patterns compare?
Advanced
In the App Router, you simply use an async server component and call fetch or a database query directly inside it, using the next.revalidate option on your fetch call to replicate the time based caching behavior that getStaticProps previously handled through its own revalidate return value.
// Pages Router
export async function getStaticProps() {
const posts = await getPosts();
return { props: { posts }, revalidate: 60 };
}
// App Router equivalent
export default async function Page() {
const res = await fetch(url, { next: { revalidate: 60 } });
const posts = await res.json();
return <PostList posts={posts} />;
}
Real-world example
A team migrating their blog from the Pages Router to the App Router replaces their getStaticProps function with a simple async server component using an equivalent revalidate option on their fetch call.
Common follow-ups: What other Pages Router specific functions need equivalents when migrating to the App Router?;Are there any behavioral differences to watch out for during this kind of migration?
Rendering (SSR/SSG/ISR);Server Components