Episode 2 — React Frontend Architecture NextJS / 2.19 — Rendering Strategies in NextJS

2.19 — Exercise Questions: Rendering Strategies

<< 2.19 Overview

A. SSR (2.19.a)

  1. Build a dashboard page that reads a cookie and fetches user-specific data with cache: 'no-store'. Measure p95 TTFB locally.
  2. Introduce three sequential awaits; record TTFB. Refactor to parallel Promise.all; compare.
  3. Add a Suspense boundary: fast header synchronous, slow panel streamed. Describe what you see in the Network panel.

B. SSG (2.19.b)

  1. Create a marketing page with no dynamic APIs. Confirm static output in build logs.
  2. Add generateStaticParams for /blog/[slug] with 50 slugs. Measure total build time.
  3. Attempt to read cookies() on that page — observe how static behavior changes (per your Next version).

C. ISR (2.19.c)

  1. Implement Pages Router style revalidate: 120 on a listing page (or App Router equivalent per docs). Verify stale then fresh behavior with timestamps in HTML.
  2. Add a CMS webhook Route Handler that calls revalidateTag('posts'). Test with curl + valid secret header.
  3. Simulate webhook failure: confirm time-based fallback still refreshes within SLA.

D. Cross-cutting & architecture

  1. Draw three boxes: CDN, origin, database. Annotate where SSR, SSG, and ISR differ on read paths.
  2. Write a one-page RFC choosing SSR vs ISR for product detail pages with inventory that changes every few seconds (hint: hybrid).
  3. Add a too-broad revalidateTag and observe over-invalidation (many routes rebuild). Replace with granular tags and document the rule.

Answers & guidance (self-check)

1. SSR + cookie + no-store

  • Expect dynamic route in build output. TTFB includes auth/session lookup + DB. Record DevTools document timing; repeat for warm server.

2. Sequential vs parallel

  • Sequential adds sum of latencies; parallel adds max (roughly). You should see TTFB drop when independent IO runs in Promise.all.

3. Suspense streaming

  • Network shows chunked response or progressive HTML depending on host. UI: header paints before slow panel resolves.

4. Pure marketing SSG

  • Build log should mark route static (wording varies by version). No cookies()/headers()/searchParams dynamic usage in that subtree.

5. generateStaticParams

  • Build time grows with slug count; watch for CMS/API rate limits. For huge sets, consider partial prerendering strategies per docs rather than infinite static paths.

6. cookies() on static page

  • Next typically opts the segment into dynamic rendering or errors in dev—do not mix private cookies with public SSG without intent.

7. ISR timestamps

  • First request after revalidate window serves stale HTML while regeneration runs; subsequent requests get fresh HTML. Stamp Date.now() or content updatedAt in HTML to prove behavior.

8. Webhook + revalidateTag

  • Handler should authenticate the webhook (shared secret/signature). Return 200 only after revalidateTag succeeds; log failures to observability.

9. Webhook failure

  • Time-based ISR still refreshes within N seconds if configured—document worst-case staleness for editors.

10. Diagram

  • SSG: build → CDN (origin rarely hit). SSR: request → origin computes → HTML (CDN may still cache carefully). ISR: first read CDN/static shell; background regen hits origin/DB on schedule or invalidation.

11. RFC hybrid

  • Example stance: SSR shell for price/stock line items; ISR for marketing/description; client poll or websocket for ultra-hot inventory if sub-second truth required.

12. Broad tags

  • Tag like content attached to every fetch causes thundering herd rebuilds. Prefer tags like post-123, author-9, plus explicit revalidatePath for hot pages when appropriate.

<< 2.19 Overview