How does Server Component fetching differ from getStaticProps and getServerSideProps?

WHAT THIS TESTS: The interviewer wants to know if you see the App Router as more than a syntax change. They are checking whether you understand that React Server Components move data fetching from the route layer into the component layer, which changes how you think about build time versus request time, prop drilling, and streaming architecture. This is fundamentally about knowing why the Pages Router required page-level exports and how the App Router removes that constraint.

A GOOD ANSWER COVERS: First, explain that getStaticProps and getServerSideProps were page-level exports in the Pages Router, meaning only the page component could fetch data and had to pass it down through props. Second, state that Server Components are async functions that can fetch data directly inside any component in the tree using standard async and await, so child components load their own data without prop drilling. Third, highlight that this enables streaming because the shell can be sent to the client while nested data promises resolve, which was not possible with the all-or-nothing behavior of getServerSideProps. Fourth, note that caching and revalidation move to the fetch call or segment configuration rather than the return object of a data function, giving granular control over static and dynamic behavior per component or route segment.

COMMON WRONG ANSWERS: A major red flag is saying Server Components are simply getServerSideProps moved into a component, because it misses the build-time versus request-time nuance and the component-level granularity. Another mistake is claiming that Server Components replace client-side state or interactivity; they are meant for server-only data and should be paired with Client Components for hooks and event handlers. Candidates also err by forgetting that getStaticProps was build-time only for the whole page, whereas the App Router can mix static and dynamic data in the same page via different segments and fetch configurations.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a slow database query in a Server Component without blocking the entire page, which is where streaming and Suspense boundaries come in. They might ask when you would still use a Client Component for data fetching, such as for user-specific live data that must be fresh on every render and is not cacheable. They could also probe how caching differs, asking about the fetch cache, revalidatePath, or the unstable_cache API compared to the old revalidate key.

ONE CONCRETE EXAMPLE: Imagine an e-commerce product page. In the Pages Router, getStaticProps might fetch product details at build time and getServerSideProps might fetch personalized recommendations at request time, but you could not use both on the same page easily. In the App Router, the ProductDetails Server Component fetches static product data with a cached fetch call, while a nested RecommendedProducts Server Component fetches personalized data with cache no-store, and both stream in independently without passing props through intermediate layout components.