Unit 2: Rendering Strategies and Data Fetching - Subjective Questions

Server-Side Rendering (SSR) is a rendering strategy in which the server generates the HTML for a page in response to each request or when required.

Request-response lifecycle:

• The client sends a request for a page.
• The server receives the request and fetches the required data.
• The application renders the page components into HTML on the server.
• The server sends the generated HTML to the browser.
• The browser displays the initial content.
• JavaScript files are downloaded and executed.
• The page is hydrated so that interactive components can respond to user actions.

Advantages:

• Faster display of meaningful content on the first visit.
• Better search-engine optimization because the response contains rendered HTML.
• Suitable for personalized or frequently changing content.

Limitations:

• The server performs rendering work for every request.
• Response time can increase when data fetching or rendering is slow.
• Server infrastructure must be capable of handling rendering workloads.

Static Site Generation (SSG) is a rendering strategy in which pages are generated as HTML files during the build process rather than when a user requests them.

Working process:

• The developer runs a production build.
• The application fetches data required for each page.
• The pages are rendered into static HTML files.
• The files are deployed to a web server or content delivery network.
• The CDN serves the files directly to users.

Advantages:

• Very fast response times because prebuilt files are served directly.
• Excellent scalability and low server-processing requirements.
• Strong security because there is less runtime server logic.
• Good SEO performance.

Limitations:

• Content may become outdated after deployment.
• A rebuild may be required when content changes.
• It is less suitable for highly personalized or real-time pages.

Suitable use cases: documentation websites, blogs, portfolios, marketing pages, product catalogs with infrequent changes, and technical guides.

Incremental Static Regeneration (ISR) allows statically generated pages to be updated after deployment without rebuilding the entire website.

Typical process:

• A page is generated statically during the build or on its first request.
• The generated page is cached and served quickly.
• After a configured revalidation period, the cached page is considered stale.
• A later request can trigger regeneration of the page in the background.
• Users continue receiving the existing cached version while the new version is generated.
• Future requests receive the updated page.

How ISR combines strategies:

• It provides the performance and scalability of SSG through cached HTML.
• It provides fresher content by regenerating selected pages at runtime.
• It avoids the cost of rendering every page for every request, as in SSR.

Use cases: news pages, product listings, event schedules, and content-heavy sites where data changes periodically but does not need to be updated for every request.

Trade-off: users may briefly receive stale content during the revalidation period.

Client-Side Rendering (CSR) is a strategy in which the server sends a minimal HTML document and JavaScript bundles, and the browser creates most of the page content.

CSR loading process:

• The browser requests the page.
• The server returns a basic HTML shell.
• JavaScript bundles are downloaded and executed.
• The application fetches data from APIs in the browser.
• The browser generates and updates the user interface.

CSR compared with SSR:

CSR can provide smooth navigation after the initial load, but it may perform poorly on slow devices or networks if JavaScript bundles are large.

Key distinction:

• SSR prioritizes request-time freshness.
• SSG prioritizes build-time performance.
• ISR balances static performance with periodic regeneration.
• CSR delegates rendering and often data fetching to the browser.

The correct strategy depends on how frequently data changes, whether pages require personalization, how important SEO is, and how much server processing is acceptable.

Rendering strategy selection should be based on the application's content, users, and operational requirements.

Important factors:

• Data freshness: Frequently changing data may require SSR or CSR, while stable data is suitable for SSG.
• Personalization: User-specific pages generally require SSR or CSR because the content differs between users.
• SEO requirements: Public content that must be indexed benefits from SSR, SSG, or ISR.
• Initial page performance: SSG and ISR usually provide fast initial responses; SSR depends on server execution time.
• Interactivity: Highly interactive pages often use CSR or a combination of server and client components.
• Build duration: SSG can become expensive when a site contains thousands of pages.
• Infrastructure cost: SSR requires runtime server resources, while static deployment can reduce costs.
• Caching requirements: Static HTML is easier to cache globally than personalized SSR responses.
• Security and data access: Sensitive data should generally be fetched on the server rather than exposed to the browser.

A single application can use different strategies for different routes instead of applying one strategy universally.

Server Components are components that execute on the server and send rendered output or a serialized component payload to the client rather than sending all component code to the browser.

Execution model:

• The server executes the component.
• It can access server-side resources such as databases, files, or protected services.
• The result is converted into output that the client can render.
• The component's implementation does not need to be included in the client JavaScript bundle.

Benefits:

• Smaller client-side JavaScript bundles.
• Better initial loading performance.
• Direct access to server-only resources.
• Reduced exposure of secrets and private credentials.
• Improved separation between data access and browser interaction.

Limitations:

• They cannot directly use browser-only APIs such as window or localStorage.
• They are not appropriate for event handlers and highly interactive behavior.
• Their data and output must follow the framework's serialization rules.
• Developers must understand the boundary between server and client execution.

Server Components are particularly useful for data-heavy, mostly static portions of a page.

Client Components are components whose code is sent to the browser and executed there. They are required when a component needs browser capabilities or direct user interaction.

Client Components are appropriate when they use:

• Event handlers such as click, input, or submit events.
• State and lifecycle behavior.
• Browser APIs such as window, document, or localStorage.
• Client-side subscriptions, timers, or animations.
• Interactive forms, menus, dialogs, and real-time widgets.

Interaction with Server Components:

• A Server Component can render a Client Component as part of its output.
• Server Components can provide initial data to Client Components through serializable properties.
• The Client Component hydrates in the browser and becomes interactive.
• Client Components should be kept as small as possible to reduce the JavaScript bundle.

Important limitation: sensitive server-only values should not be passed to a Client Component because they may become visible in the browser.

A good design keeps data access and noninteractive rendering on the server while isolating interaction in client-side components.

Combined use: a page can be composed mostly of Server Components, with small Client Components embedded wherever user interaction is required. This reduces client-side JavaScript while preserving a responsive user experience.

The Fetch API is a browser and server-side JavaScript interface used to make asynchronous network requests.

Basic process:

• Call fetch() with a resource URL.
• Receive a Promise representing the network operation.
• Check the response status using response.ok or response.status.
• Convert the response body into the required format, such as JSON.
• Use the parsed data to update the application.
• Handle failures with error handling logic.

Example:

async function loadUsers() {
  const response = await fetch('/api/users');

  if (!response.ok) {
    throw new Error('Unable to load users');
  }

  return response.json();
}

Important points:

• fetch() does not reject automatically for HTTP errors such as 404 or 500, so status checks are necessary.
• Network errors should be handled with try...catch.
• Request options can specify the method, headers, body, credentials, and cache behavior.
• An AbortController can cancel requests that are no longer needed.

Client-side data fetching occurs when the browser requests data after the page's JavaScript has loaded or after a user interaction.

Typical workflow:

• The component starts in a loading state.
• A request is sent to an API endpoint.
• The response is validated and parsed.
• The component stores the result in client-side state.
• The UI displays the returned data.

States that should be managed:

• Loading: Indicates that the request is still in progress.
• Success: Displays the retrieved data.
• Empty: Explains that the request succeeded but returned no records.
• Error: Presents a useful failure message and, where appropriate, a retry action.
• Refreshing: Keeps existing data visible while requesting an updated version.

Good practices:

• Avoid duplicate requests.
• Cancel requests when components are removed or parameters change.
• Validate response data.
• Avoid exposing private credentials in browser code.
• Use caching or a data-fetching library for repeated requests and synchronization.

Client-side fetching is effective for dashboards, user-specific data, filters, and content that changes frequently.

Server-side data fetching takes place on the server before or during page rendering. The server retrieves data and uses it to produce the initial page output.

Server-side fetching is useful when:

• The initial page must contain meaningful data.
• Search engines must index the content.
• Data requires protected credentials.
• The page depends on request-specific authentication.

Client-side fetching is useful when:

• Data is only needed after interaction.
• The page behaves like an application dashboard.
• Frequent updates are required after initial rendering.

Many applications combine both approaches.

Caching stores a previously generated response or data result so that it can be reused for subsequent requests.

Common cache locations:

• Browser cache.
• CDN or edge cache.
• Server-side data cache.
• Framework-level fetch or route cache.
• Client-side application data cache.

Performance benefits:

• Reduces repeated database and API requests.
• Lowers server processing requirements.
• Reduces network latency when content is served from an edge location.
• Improves page response time.
• Helps applications handle more users.

Common risks:

• Stale data: users may receive an older value.
• Incorrect cache keys: different users may receive the wrong response.
• Sensitive data leakage: personalized responses must not be shared through a public cache.
• Invalidation complexity: updates must remove or refresh affected entries.
• Inconsistent layers: browser, CDN, and server caches may hold different versions.

A caching policy should define what is cached, for how long, under which key, and how updates invalidate or revalidate the entry.

Revalidation is the process of checking whether cached data or rendered output is still current and obtaining a newer version when necessary.

Time-based revalidation:

• A cache entry is assigned a time interval.
• The entry remains usable during that interval.
• After the interval expires, the system fetches or generates fresh content.
• It is simple and suitable for content that changes predictably.
• It may leave stale content available until the next request triggers an update.

Event-based or on-demand revalidation:

• An explicit event invalidates or refreshes a cache entry.
• Events may include publishing an article, updating a product, or changing a database record.
• The next request obtains fresh content, or regeneration may happen immediately.
• It offers better freshness but requires reliable integration with data-update workflows.

Comparison:

• Time-based revalidation is easier to implement but less precise.
• On-demand revalidation is more accurate but operationally more complex.
• Both approaches can be combined to provide a maximum freshness interval and immediate updates for important changes.

Stale-while-revalidate is a caching approach in which an existing cached response is returned immediately while a background operation checks for and obtains a fresh response.

Sequence:

• A request arrives for a cached resource.
• The cache returns the existing response quickly.
• The system checks whether the response is outdated.
• If it is outdated, a background fetch obtains the latest version.
• The cache is updated for future requests.

Effect on user experience:

• Users receive content with low latency.
• They do not wait for regeneration or a slow upstream service.
• Some users may briefly see older information.
• Later requests receive the refreshed version.

Suitable content:

• Product descriptions.
• Blog posts.
• News lists with acceptable short delays.
• Public pages that are not individually personalized.

Unsuitable content:

• Account balances.
• Payment results.
• Security permissions.
• Critical real-time information.

The implementation must ensure that background refresh failures do not replace a valid cached response with unusable data.

The recommended strategy is Incremental Static Regeneration (ISR), supported by caching and scheduled or on-demand revalidation.

Justification:

• Thousands of pages would make a full SSG build slow and expensive.
• Product information does not need to be regenerated for every request.
• Cached static pages provide fast responses and good CDN performance.
• A 30-minute revalidation interval can keep information reasonably current.
• Frequently changed products can use on-demand invalidation after an inventory or price update.
• Public product pages benefit from server-generated HTML for SEO.

Suggested design:

• Generate popular pages during the build.
• Generate less frequently visited pages when first requested, if supported.
• Cache the generated output.
• Revalidate pages after 30 minutes.
• Trigger immediate revalidation for critical price or availability changes.
• Fetch private customer-specific information separately on the client or through authenticated server logic.

Pure CSR could weaken initial SEO, while pure SSR would create unnecessary rendering work for every catalog request.

A hybrid rendering application selects a rendering strategy according to the needs of each route or component.

Example architecture:

• The home page uses SSG because its content changes infrequently.
• A news listing uses ISR because it requires periodic updates.
• An account page uses SSR because it depends on authenticated user data.
• An analytics dashboard uses CSR because it is highly interactive and frequently refreshed.
• A product detail page uses server rendering for searchable product information and Client Components for filters, quantity controls, and reviews.

Benefits:

• Each page receives an appropriate balance of performance and freshness.
• Static pages can be served cheaply through a CDN.
• Sensitive or personalized data can remain on the server.
• Interactive features can be isolated to small client-side components.
• The application avoids forcing one strategy onto unrelated workflows.

Design considerations:

• Define clear server-client boundaries.
• Use consistent loading and error states.
• Establish cache rules for each route.
• Prevent personalized responses from entering shared public caches.
• Monitor build time, server latency, cache hit rate, and client bundle size.

Hydration is the process through which client-side JavaScript attaches behavior and event handlers to HTML that was already rendered on the server.

Role of hydration:

• SSR provides the initial HTML quickly.
• The browser displays that HTML before the full application becomes interactive.
• JavaScript loads and reconstructs the relevant client components.
• Event handlers and state behavior are attached to the existing markup.

Common hydration problems:

• Markup mismatch: server and client produce different HTML.
• Nondeterministic rendering: timestamps, random values, or environment-dependent values differ.
• Browser-only APIs on the server: code accesses window or document before hydration.
• Incorrect data timing: the client renders different data from the server-rendered result.
• Excessive hydration: too many components require client JavaScript, increasing load time.

Prevention:

• Keep initial output deterministic.
• Move browser-only logic into client-side lifecycle logic.
• Pass consistent initial data.
• Limit Client Components to interactive areas.
• Treat hydration warnings as correctness issues rather than ignoring them.

Reliable Fetch API usage requires handling network failures, unsuccessful HTTP responses, invalid data, and requests that are no longer relevant.

Request cancellation:

• Create an AbortController for the request.
• Pass its signal to fetch().
• Call controller.abort() when a component is removed or a newer request supersedes the old one.
• Treat an abort as a controlled outcome rather than displaying it as a user-facing error.

HTTP error handling:

• Check response.ok or the status code.
• Throw or return a structured error for 4xx and 5xx responses.
• Do not assume that a resolved Fetch promise means the request succeeded.

Response validation:

• Parse the response according to its content type.
• Verify required fields and expected data types.
• Reject malformed or incomplete data before rendering it.

User-facing behavior:

• Display loading, error, empty, and retry states.
• Log diagnostic details on the server or through an approved monitoring system.
• Avoid exposing internal stack traces, credentials, or sensitive response details to users.

The public article content and the personalized saved-article list have different requirements and should be handled separately.

Public article content:

• Render it on the server using SSG, ISR, or SSR depending on update frequency.
• Fetch the article data on the server.
• Cache the public result at the CDN or framework level when appropriate.
• Send rendered HTML so that the content loads quickly and can be indexed.

Personalized saved-article list:

• Fetch it using authenticated server-side logic or a protected API.
• Ensure the response is not stored in a shared public cache.
• Use a Client Component if the list supports save, remove, filter, or optimistic updates.
• Pass only safe, serialized initial data from the server when server rendering is used.

Security requirements:

• Keep authentication checks on the server.
• Never expose database credentials or private tokens to the browser.
• Include the user identity in the cache key when personalized responses are cached privately.

This design keeps public content fast and cacheable while preserving privacy and interactivity for user-specific data.