Questions

1 of 33

1Explain server-side rendering (SSR) in Next.js.

2List the benefits of Server-Side Rendering in Next.js.

3What are server components?

4How to use server components in next js?

5What is the React Server Component Payload (RSC)?

6Describe how server components are rendered.

7Describe server rendering strategies

8How can you keep Server-only Code out of the Client Environment

9What are the issues of using context provider at the root of the application?

10List dynamic functions available to server components.

11List all Dynamic APIs.

12How do we opt for Static Rendering, Dynamic Rendering and Streaming?

13Explain the difference between SSR, SSG, ISR, and CSR in Next.js. When would you choose each?

14How does getServerSideProps work internally? What is its execution context?

15What are the performance trade-offs of SSR vs SSG in a high-traffic production app?

16How does Next.js handle hydration? What is a hydration mismatch, and how do you debug it?

17What happens when getServerSideProps throws an error? How do you handle it gracefully?

18How would you architect a Next.js app that needs both personalised (SSR) and cacheable (SSG) pages at scale?

19Explain the App Router vs Pages Router SSR model differences. How does React Server Components change the SSR paradigm?

20How do React Server Components (RSC) differ from traditional SSR? Can they be used together?

21How does streaming SSR work in Next.js 13+? What role does Suspense play?

22How would you implement partial hydration or Islands Architecture in Next.js?

23Explain how Next.js handles data fetching waterfall problems in SSR and how you'd mitigate them.

24How would you implement partial hydration or Islands Architecture in Next.js?

25How do you implement caching strategies for SSR responses in Next.js? (CDN, Cache-Control, stale-while-revalidate)

26How would you reduce TTFB (Time to First Byte) in an SSR-heavy Next.js app?

27What's the difference between fetch caching in the App Router vs traditional getServerSideProps?

28How do you avoid redundant database/API calls across multiple server components on the same page?

29How do you securely handle authentication in SSR? What are the risks of passing tokens via cookies vs headers?

30How do you prevent sensitive server-side data from leaking to the client bundle?

31How would you implement role-based rendering on the server without exposing protected routes to the client?

32How do you debug SSR-only issues that don't appear in local development?

33How can we control dynamic rendering behaviour in next js?

01 / 33

Explain server-side rendering (SSR) in Next.js.

Server-side rendering (SSR) is a technique used in web development to improve the performance and SEO of web applications. In the context of Next.js, SSR refers to the process of rendering React components on the server side before sending the fully-rendered HTML to the client's browser. This approach has several advantages over traditional client-side rendering (CSR), where the rendering process occurs on the client's device.

Here's how server-side rendering works in Next.js:

1
User Requests a Page: When a user requests a page of your Next.js application by entering a URL or clicking a link, the server receives the request.
2
Server-side Rendering: In a Next.js application configured for SSR, the server renders the requested page on the server side. This involves executing the relevant React components for the requested page and generating the HTML content that represents the page's initial state.
3
HTML Response: Once the rendering process is complete, the server sends the fully-rendered HTML content to the client's browser as a response to the user's request. This HTML content includes the initial data and UI of the requested page.
4
Client Hydration: When the browser receives the HTML content, it also downloads the necessary JavaScript bundles that contain the React components and logic. The JavaScript code takes over the interactivity of the page, attaching event listeners, handling user interactions, and managing dynamic updates.
5
Interactivity and Routing: From this point on, the application behaves like a traditional React application, handling client-side routing, state management, and dynamic updates as users interact with the page.