; // output only\n}\n// Client bundle impact of marked + highlight.js: 0 bytes."}],"references":[{"title":"Next.js Docs: Server Components — reducing client bundle size","url":"https://nextjs.org/docs/app/building-your-application/rendering/server-components"},{"title":"React Docs: RSC payload — what crosses the wire","url":"https://react.dev/reference/rsc/server-components"}],"tips":["Measure the win: compare the client bundle before/after moving a heavy component server-side — libraries used only in server components contribute zero bytes.","The RSC payload is the new thing to watch: a server tree that renders enormous data as props can make the payload itself heavy — prune what you render."],"challenges":[],"mcqs":[{"id":"nextjs-0ec1-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What does a Server Component contribute to the client bundle?","intro":"Payload model.","images":[],"followUp":"What about a charting library it imports?","code":"","choices":[{"id":"a","text":"Nothing — only its rendered output crosses; its code and dependencies stay server-side"},{"id":"b","text":"Its full source, minified"},{"id":"c","text":"A stub for hydration"},{"id":"d","text":"Only its CSS"}],"correctAnswerIds":["a"],"explanation":"This is the headline feature: server-only dependencies (DB clients, chart libs, markdown parsers) contribute zero client bytes.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Server Components — reducing client bundle size","url":"https://nextjs.org/docs/app/building-your-application/rendering/server-components"}},"databaseId":"6ab19578b8dd2d82472cb354"},{"id":"nextjs-0ec1-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Where does hydration cost go with RSC?","intro":"Hydration surface.","images":[],"followUp":"What still hydrates?","code":"","choices":[{"id":"a","text":"Down to only the Client Components — server-rendered markup needs no attachment"},{"id":"b","text":"Up — more work than before"},{"id":"c","text":"Nowhere — hydration is gone"},{"id":"d","text":"To the server"}],"correctAnswerIds":["a"],"explanation":"Interactivity islands hydrate; everything else is static markup. The client's job shrinks to exactly the interactive parts.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Server Components — reducing client bundle size","url":"https://nextjs.org/docs/app/building-your-application/rendering/server-components"}},"databaseId":"6ab19578b8dd2d82472cb355"},{"id":"nextjs-0ec1-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: RSC eliminates the need for code splitting.","intro":"Scope of the win.","images":[],"followUp":"Where does code splitting still matter?","code":"","choices":[{"id":"a","text":"False — client islands and their dependencies still need splitting; RSC shrinks what needs splitting"},{"id":"b","text":"True — bundles are dead"},{"id":"c","text":"True, except in dev"},{"id":"d","text":"False — RSC increases bundle size"}],"correctAnswerIds":["a"],"explanation":"The remaining client code is exactly where lazy-loading/dynamic imports still apply. RSC removes whole categories, not the concept.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Server Components — reducing client bundle size","url":"https://nextjs.org/docs/app/building-your-application/rendering/server-components"}},"databaseId":"6ab19578b8dd2d82472cb356"},{"id":"nextjs-0ec1-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A 300KB markdown renderer is used to render blog posts. Move to a server component — client impact?","intro":"Quantified scenario.","images":[],"followUp":"What ships instead?","code":"","choices":[{"id":"a","text":"Zero bytes of that library — the browser receives rendered HTML for the post content"},{"id":"b","text":"Still 300KB — libraries always ship"},{"id":"c","text":"150KB — half off"},{"id":"d","text":"Only on slow networks"}],"correctAnswerIds":["a"],"explanation":"Parsing markdown on the server produces HTML; the parser itself never crosses. The visitor downloads content, not the tool that made it.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Server Components — reducing client bundle size","url":"https://nextjs.org/docs/app/building-your-application/rendering/server-components"}},"databaseId":"6ab19579b8dd2d82472cb357"}]},{"id":"6aa2b1d3a7147974707d0ec2","question":"How do you decide where a use client boundary belongs?","shortAnswer":"Place it at the smallest subtree that needs state, event handlers, or browser APIs so interactive behavior works without converting the entire page and its data access into client code.","longAnswer":"Boundary placement is a payload decision: every 'use client' module ships and hydrates, along with its entire import subtree. The rule is to push the boundary to the smallest subtree that genuinely needs client capabilities — state, effects, event handlers, browser APIs — so the page around it stays server-rendered. Practical patterns: leaf boundaries (a Like button, not the whole card), children slots (server-rendered content passed INTO an interactive wrapper), and prop-based composition (data crosses as serializable props, behavior stays server-side). Pushing boundaries up (a whole page or layout) converts everything beneath to client code — bundle size, hydration cost, and lost server data access — usually to reach one interactive element.","images":[],"codeSnippets":[{"title":"Three boundary shapes, smallest wins","language":"tsx","code":"// 1) LEAF: smallest subtree that needs interactivity\n// like-button.tsx ('use client') — 2KB hydrated; card stays server-side.\n\n// 2) CHILDREN SLOT: interactive wrapper AROUND server content\n// filter-shell.tsx ('use client')\nexport function FilterShell({ children }: { children: React.ReactNode }) {\n const [filter, setFilter] = useState('all');\n return (\n

\n {/* client */}\n {children} {/* server-rendered grid stays server-side */}\n

\n );\n}\n\n// 3) ANTI-PATTERN: page-level boundary\n// 'use client' on page.tsx → entire subtree ships + hydrates for ONE dropdown.\n// Fix: move 'use client' down to the dropdown."}],"references":[{"title":"Next.js Docs: Moving Client Components to the leaves","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-to-the-leaves"},{"title":"React Docs: use client — boundaries and subtree effects","url":"https://react.dev/reference/rsc/use-client"}],"tips":["Before adding 'use client' to a file, name the specific client capability it needs. If the answer is 'a click handler', the boundary belongs on a smaller component.","The children-slot pattern is the fix for oversized boundaries: {serverRenderedContent} keeps content server-side while the wrapper handles interaction."],"challenges":[],"mcqs":[{"id":"nextjs-0ec2-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A product card shows static info plus one heart button. Where's the boundary?","intro":"Placement decision.","images":[],"followUp":"What does the card remain?","code":"","choices":[{"id":"a","text":"On the heart button only — the card stays a Server Component"},{"id":"b","text":"On the whole card"},{"id":"c","text":"On the page"},{"id":"d","text":"On the layout"}],"correctAnswerIds":["a"],"explanation":"Leaf boundaries hydrate one button instead of every card; the card's markup ships with zero client JS.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Moving Client Components to the leaves","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-to-the-leaves"}},"databaseId":"6ab19577b8dd2d82472cb350"},{"id":"nextjs-0ec2-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why does an oversized boundary hurt beyond bundle size?","intro":"Cost model.","images":[],"followUp":"What's the hydration consequence?","code":"","choices":[{"id":"a","text":"Hydration work scales with the client tree — more components to attach, more interaction blocking"},{"id":"b","text":"It disables streaming"},{"id":"c","text":"It forces dynamic rendering"},{"id":"d","text":"It breaks SEO"}],"correctAnswerIds":["a"],"explanation":"Hydration executes the client tree: more 'use client' surface = more main-thread work before the page is fully interactive.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Moving Client Components to the leaves","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-to-the-leaves"}},"databaseId":"6ab19577b8dd2d82472cb351"},{"id":"nextjs-0ec2-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: passing server-rendered content as children to a client component requires it to be serializable as data.","intro":"Slot mechanics.","images":[],"followUp":"What actually crosses the boundary?","code":"","choices":[{"id":"a","text":"False — children are rendered ON THE SERVER first; the client wrapper receives the rendered result as a slot"},{"id":"b","text":"True — children are serialized as source"},{"id":"c","text":"True — they re-render on the client"},{"id":"d","text":"False — children can't be server components"}],"correctAnswerIds":["a"],"explanation":"This is why the pattern is safe: server content executes where the server lives, and the client wrapper just positions its output.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Moving Client Components to the leaves","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-to-the-leaves"}},"databaseId":"6ab19578b8dd2d82472cb352"},{"id":"nextjs-0ec2-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A team makes layout.tsx client 'for the theme toggle'. Impact and fix?","intro":"Review scenario.","images":[],"followUp":"What pattern keeps the toggle interactive?","code":"","choices":[{"id":"a","text":"Everything under it becomes client — extract a small ThemeToggle client island instead"},{"id":"b","text":"Fine — layouts are small"},{"id":"c","text":"Fix by removing the toggle"},{"id":"d","text":"Fix with force-static"}],"correctAnswerIds":["a"],"explanation":"A client root layout is the maximum blast radius: the whole app hydrates. One small island keeps the toggle and the server tree.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Moving Client Components to the leaves","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-to-the-leaves"}},"databaseId":"6ab19578b8dd2d82472cb353"}]},{"id":"6aa2b1d3a7147974707d0ec3","question":"How do you handle non-serializable data from a Server Component?","shortAnswer":"Transform database records, dates, class instances, and other values into serializable DTOs before crossing the boundary, or keep the consumer on the server.","longAnswer":"The Server→Client boundary serializes, so class instances, Date-like library objects, Map/Set, streams, database clients, and functions cannot cross — the transport throws. The fixes are structural: convert to DTOs at the boundary (plain objects with plain types, Dates allowed), handle conversion in the server component that owns the data, or keep the consumer server-side when conversion loses meaning (render on the server, ship markup). For data that's genuinely interactive-shaped but non-serializable (a tree with methods), send the plain state and reconstruct client-side. The error message is loud and actionable; the discipline is treating the boundary as a versioned API surface — explicit DTOs also decouple your DB schema from your UI.","images":[],"codeSnippets":[{"title":"DTO conversion at the boundary","language":"tsx","code":"// app/reports/page.tsx (server)\nimport { ReportChart } from './report-chart'; // 'use client'\n\nexport default async function ReportsPage() {\n const rows = await db.metric.findMany({\n where: { userId: session.userId },\n include: { owner: true },\n });\n\n // ❌ — class instances, Maps, methods\n\n // ✅ Minimal, plain, precomputed:\n const points = rows.map((r) => ({\n t: r.createdAt.toISOString(), // Dates → ISO strings for absolute safety\n v: r.value,\n label: r.owner.name,\n }));\n return ; // only what the chart renders crosses\n}"}],"references":[{"title":"Next.js Docs: Serialization rules across the RSC boundary","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#passing-data-between-server-and-client-components"},{"title":"React Docs: Server Components — serializable props","url":"https://react.dev/reference/rsc/server-components#serializable-parameters"}],"tips":["Dates serialize; custom date LIBRARIES (dayjs instances, Temporal objects) often don't — convert to Date or ISO strings at the boundary.","The DTO layer doubles as a security boundary: explicit field picking means you never accidentally render an internal field (hashedPassword, internalNotes) into client props."],"challenges":[],"mcqs":[{"id":"nextjs-0ec3-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which value crosses the Server→Client boundary without conversion?","intro":"Serialization rules.","images":[],"followUp":"Which needs a DTO?","code":"","choices":[{"id":"a","text":"A Date object — plain data types and Dates cross; class instances don't"},{"id":"b","text":"A Prisma client instance"},{"id":"c","text":"A Map"},{"id":"d","text":"A database cursor"}],"correctAnswerIds":["a"],"explanation":"The transport supports JSON-ish data plus Dates. Everything with methods, live handles, or custom prototypes needs conversion.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Serialization rules across the RSC boundary","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#passing-data-between-server-and-client-components"}},"databaseId":"6ab1957db8dd2d82472cb36e"},{"id":"nextjs-0ec3-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Where should DTO conversion live?","intro":"Architecture placement.","images":[],"followUp":"What's the side benefit?","code":"","choices":[{"id":"a","text":"In the server component (or data layer) that owns the data, before props cross"},{"id":"b","text":"In the client component's useEffect"},{"id":"c","text":"In middleware"},{"id":"d","text":"Nowhere — serialize automatically"}],"correctAnswerIds":["a"],"explanation":"Conversion belongs to the data's owner — and explicit field-picking doubles as the guarantee that only intended fields ship.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Serialization rules across the RSC boundary","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#passing-data-between-server-and-client-components"}},"databaseId":"6ab1957db8dd2d82472cb36f"},{"id":"nextjs-0ec3-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: a Map passed as a prop serializes to an empty object.","intro":"Silent failure shapes.","images":[],"followUp":"What's the correct transport for key-value data?","code":"","choices":[{"id":"a","text":"Worse — it throws (the transport rejects it); plain objects/arrays are the key-value transport"},{"id":"b","text":"True — Maps silently lose entries"},{"id":"c","text":"True — Maps serialize fully"},{"id":"d","text":"False — Maps are the preferred type"}],"correctAnswerIds":["a"],"explanation":"The boundary fails loudly on Maps/Sets — convert to entries arrays or plain objects before crossing.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Serialization rules across the RSC boundary","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#passing-data-between-server-and-client-components"}},"databaseId":"6ab1957db8dd2d82472cb370"},{"id":"nextjs-0ec3-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A client chart component needs a 10k-row dataset with computed methods. Design?","intro":"Heavy interactive data scenario.","images":[],"followUp":"What crosses the wire?","code":"","choices":[{"id":"a","text":"Server computes, ships a minimal plain-array DTO (only the fields the chart renders); methods stay server-side"},{"id":"b","text":"Ship the class instances"},{"id":"c","text":"Ship the DB cursor"},{"id":"d","text":"Move the DB to the client"}],"correctAnswerIds":["a"],"explanation":"Payload size and serializability both argue for minimal DTOs: precompute on the server, ship the shape the chart actually consumes.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Serialization rules across the RSC boundary","url":"https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#passing-data-between-server-and-client-components"}},"databaseId":"6ab1957db8dd2d82472cb371"}]},{"id":"6aa2b1d3a7147974707d0ec4","question":"How do you avoid waterfalls between nested Server Components?","shortAnswer":"Start independent data work early, share promises or cached request functions, use parallel route segments where useful, and reserve sequential fetching for real data dependencies.","longAnswer":"Nested Server Components waterfall when a parent awaits its data before rendering children that each await their own — every level adds a full round trip, so three nested layers serial into three sequential fetches even though nothing actually depends in sequence. The fixes: hoist data fetching to the highest common parent and fan out with Promise.all when children need different resources; use the preload pattern (start fetches early, pass promises down, await them independently in each component); or give siblings their own fetches and let request memoization/Data Cache absorb the overlap. React is not a dependency manager — sibling awaits inside parallel components are fine, but an await that gates a child's render is the waterfall you have to see.","images":[],"codeSnippets":[{"title":"Waterfall vs parallel vs preload","language":"tsx","code":"// ❌ WATERFALL: each level awaits before rendering children\nexport default async function Bad() {\n const user = await getUser();\n return ; // Profile awaits its own data → serial hop 2\n}\n\n// ✅ PARALLEL: fan out at the highest common parent\nexport default async function Good() {\n const [user, activity] = await Promise.all([getUser(), getActivity()]);\n return (\n <>\n \n \n \n );\n}\n\n// ✅ PRELOAD: start early, await in the owning component\nexport default function Page() {\n const userPromise = getUser(); // starts NOW\n const metaPromise = getMeta(); // starts NOW (concurrently)\n return (\n <>\n

{/* awaits internally */}\n

{/* awaits internally */}\n \n );\n}"}],"references":[{"title":"Next.js Docs: Streaming and parallel data fetching","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#parallel-data-fetching"},{"title":"Next.js Docs: Request memoization — deduplicating fetches","url":"https://nextjs.org/docs/app/building-your-application/caching#request-memoization"}],"tips":["Draw the await graph before optimizing: an edge from 'parent awaits' → 'child renders' is a serial hop; edges between siblings are free parallelism.","The preload pattern (getColA(), getColB() kicked off in the page, promises passed to children) keeps data fetching parallel while components stay decoupled."],"challenges":[],"mcqs":[{"id":"nextjs-0ec4-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A layout awaits user data, then renders a page that awaits its own data. What's the timing shape?","intro":"Waterfall recognition.","images":[],"followUp":"What's the fix?","code":"","choices":[{"id":"a","text":"Sequential — the page's fetch can't start until the layout's finishes; hoist both into a Promise.all"},{"id":"b","text":"Parallel — all fetches start together"},{"id":"c","text":"Cached — no network involved"},{"id":"d","text":"Random per region"}],"correctAnswerIds":["a"],"explanation":"An awaited parent render blocks child rendering entirely: two network hops serialized. Starting both together halves the wall time.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Streaming and parallel data fetching","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#parallel-data-fetching"}},"databaseId":"6ab19583b8dd2d82472cb392"},{"id":"nextjs-0ec4-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"How does the preload pattern eliminate nested waterfalls?","intro":"Technique.","images":[],"followUp":"What do children receive?","code":"","choices":[{"id":"a","text":"The parent starts all fetches immediately and passes promises down; each child awaits only its own"},{"id":"b","text":"Children fetch harder"},{"id":"c","text":"Data is duplicated into HTML"},{"id":"d","text":"It disables caching"}],"correctAnswerIds":["a"],"explanation":"Promises started together run concurrently; children await already-in-flight work. Dependency of shape, not of time.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Streaming and parallel data fetching","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#parallel-data-fetching"}},"databaseId":"6ab19583b8dd2d82472cb393"},{"id":"nextjs-0ec4-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: sibling components that each await different fetches are a waterfall.","intro":"Parallelism model.","images":[],"followUp":"What actually serializes?","code":"","choices":[{"id":"a","text":"False — siblings render concurrently; waterfalls come from awaits gating renders down the tree"},{"id":"b","text":"True — any await is serial"},{"id":"c","text":"True, unless cached"},{"id":"d","text":"False — waterfalls only exist client-side"}],"correctAnswerIds":["a"],"explanation":"React renders sibling subtrees in parallel — two awaiting siblings cost max(t1, t2), not t1 + t2. The killer is await-before-render chains.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Streaming and parallel data fetching","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#parallel-data-fetching"}},"databaseId":"6ab19583b8dd2d82472cb394"}]},{"id":"6aa2b1d3a7147974707d0ec5","question":"How do you stream a slow dashboard panel without delaying the shell?","shortAnswer":"Put the slow panel behind its own Suspense boundary and loading fallback, keep the shell and independent panels outside that boundary, and stream each result as it resolves.","longAnswer":"The shell delays whenever anything before its flush awaits — so the slow panel's data fetch must move OUT of the shell's critical path: render the panel inside its own Suspense boundary, and do the slow fetch INSIDE the suspended component (not in the page before the boundary). The page function then returns instantly (shell flushes with the fallback), the slow component streams when its data lands. Supporting practices: give the slow fetch its own cached/tags policy so repeat visits hit the Data Cache; keep the fallback sized like the panel (no shift); ensure no shared parent awaits the same slow data outside the boundary (that would re-serialize it); and consider streaming order — the slowest segment last means the user gets maximum content before the final piece fills in.","images":[],"codeSnippets":[{"title":"Slow panel off the shell's critical path","language":"tsx","code":"// app/dashboard/page.tsx — the page NEVER awaits the slow query\nimport { Suspense } from 'react';\n\nexport default function Dashboard() {\n return (\n <>\n

\n {/* fast: ships with the shell */}\n }> {/* sized like the panel */}\n {/* its fetch lives HERE */}\n \n \n );\n}\n\n// app/dashboard/slow-analytics.tsx — server component, awaits inside\nexport default async function SlowAnalytics() {\n const rows = await getQuarterlyAnalytics(); // 4s query, cached via tags/revalidate\n return ;\n}\n// Timeline: shell flushes at ~200ms with the skeleton; the panel streams\n// in at ~4s (or instantly on cache hits). Nothing else ever waits."}],"references":[{"title":"Next.js Docs: Streaming — moving slow work below Suspense","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"},{"title":"React Docs: Suspense — suspending data-dependent components","url":"https://react.dev/reference/react/Suspense#suspending-a-component-while-data-is-loading"}],"tips":["The one-line test: if the page function itself awaits the slow call before returning JSX, the shell waits — move the await inside a component wrapped by .","A slow panel that's cached (tags/revalidate) converts 'always slow' into 'slow once' — combine the boundary with a fetch policy."],"challenges":[],"mcqs":[{"id":"nextjs-0ec5-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Where must the slow fetch live so the shell isn't delayed?","intro":"Critical-path rule.","images":[],"followUp":"What flushes first?","code":"","choices":[{"id":"a","text":"Inside the suspended panel component — the page returns immediately and the shell flushes with the fallback"},{"id":"b","text":"In the page before returning JSX"},{"id":"c","text":"In the layout"},{"id":"d","text":"Client-side only"}],"correctAnswerIds":["a"],"explanation":"Anything awaited in the page body gates the shell. The await inside a Suspense-wrapped child defers only that segment.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Streaming — moving slow work below Suspense","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}},"databaseId":"6ab1958eb8dd2d82472cb3cb"},{"id":"nextjs-0ec5-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What makes the panel's slowness disappear on repeat visits?","intro":"Cache pairing.","images":[],"followUp":"Which layer?","code":"","choices":[{"id":"a","text":"Caching the panel's fetch (revalidate/tags) — the Data Cache serves it fast after the first hit"},{"id":"b","text":"A bigger fallback"},{"id":"c","text":"More boundaries"},{"id":"d","text":"Client-side polling"}],"correctAnswerIds":["a"],"explanation":"Streaming hides the wait on cold loads; the Data Cache removes the wait on warm ones. Together they cover both cases.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Streaming — moving slow work below Suspense","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}},"databaseId":"6ab1958eb8dd2d82472cb3cc"},{"id":"nextjs-0ec5-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: awaiting the slow query in the page AND wrapping the panel in Suspense still delays the shell.","intro":"Common mistake.","images":[],"followUp":"Why?","code":"","choices":[{"id":"a","text":"True — the page's await runs before the shell can flush; the boundary never gets a chance"},{"id":"b","text":"False — Suspense fixes it"},{"id":"c","text":"False, if using PPR"},{"id":"d","text":"True, only in dev"}],"correctAnswerIds":["a"],"explanation":"Suspense can only defer what's thrown INSIDE a boundary. A page-level await blocks everything — the boundary is decoration.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Streaming — moving slow work below Suspense","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}},"databaseId":"6ab1958eb8dd2d82472cb3cd"}]},{"id":"6aa2b1d3a7147974707d0ec6","question":"What are the tradeoffs of putting a Suspense boundary too high or too low?","shortAnswer":"A high boundary protects the user from a blank large region but delays more content behind one fallback; a low boundary streams more detail but can create fragmented or unstable loading UI.","longAnswer":"Suspense boundary placement is a UX-perf dial. Too high (one boundary wrapping the whole page): the fallback becomes the de-facto page — users stare at a generic skeleton even when 90% of content is ready, the shell you paid for is wasted, and one slow segment delays the appearance of everything under the boundary. Too low (a boundary around every small piece): many independent skeletons pop in and out causing layout churn/CLS, the per-boundary fallback markup adds payload, and fine-grained boundaries can turn one logical view into a jigsaw of loading states that's harder to reason about. The sweet spot follows content value: boundaries around slow, independent segments whose fallbacks approximate the final layout (skeletons sized like the content), with static/shared content outside any boundary so it renders with the shell.","images":[],"codeSnippets":[{"title":"Boundary placement: right-sized","language":"tsx","code":"export default function Analytics() {\n return (\n <>\n {/* Static header + summary: outside any boundary — ships with the shell */}\n

\n \n\n {/* Two panels depending on the SAME slow report query: one boundary,\n one skeleton shaped like both panels → no churn */}\n }>\n {/* internally awaits getReport() once (memoized) */}\n \n\n {/* Independent slow segment: its own boundary + realistic fallback */}\n }> {/* same size as content */}\n \n \n \n );\n}\n// ❌ }>{everything}\n// ❌ }> ×20"}],"references":[{"title":"Next.js Docs: loading.js and Suspense boundaries — placement guidance","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"},{"title":"React Docs: Suspense — granular boundaries and fallbacks","url":"https://react.dev/reference/react/Suspense"}],"tips":["Skeleton fidelity is the cheap win: a fallback that matches the incoming segment's size/shape eliminates the layout shift and feels 'loaded' sooner.","Rule of thumb: boundary = independent data dependency + visible UI region. Same dependency → shared boundary; tiny region → probably belongs to the parent boundary."],"challenges":[],"mcqs":[{"id":"nextjs-0ec6-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What's the cost of ONE boundary around an entire page?","intro":"Too-high placement.","images":[],"followUp":"What does the user see while the slowest segment loads?","code":"","choices":[{"id":"a","text":"A generic skeleton as the de-facto page — ready content is hidden behind the slowest sibling"},{"id":"b","text":"Nothing — content still shows"},{"id":"c","text":"Faster loads overall"},{"id":"d","text":"A 500 error"}],"correctAnswerIds":["a"],"explanation":"All children inside one boundary share its fate: the page appears only when the slowest child resolves — streaming's benefit is forfeited.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: loading.js and Suspense boundaries — placement guidance","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}},"databaseId":"6ab1958db8dd2d82472cb3c7"},{"id":"nextjs-0ec6-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What's the cost of a boundary around every tiny widget?","intro":"Too-low placement.","images":[],"followUp":"What visual artifact results?","code":"","choices":[{"id":"a","text":"Layout churn/CLS as many skeletons pop in at different times, plus fallback markup overhead"},{"id":"b","text":"A single skeleton"},{"id":"c","text":"Slower data fetching"},{"id":"d","text":"Nothing — it's ideal"}],"correctAnswerIds":["a"],"explanation":"Each independent boundary resolves independently: fine granularity multiplies reflow events unless fallbacks reserve real space.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: loading.js and Suspense boundaries — placement guidance","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}},"databaseId":"6ab1958db8dd2d82472cb3c8"},{"id":"nextjs-0ec6-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: content that's shared/static should sit inside a Suspense boundary for consistency.","intro":"What belongs outside.","images":[],"followUp":"Where does it render?","code":"","choices":[{"id":"a","text":"False — shared/static content renders with the shell instantly; boundaries are for slow, independent segments"},{"id":"b","text":"True — boundaries improve all content"},{"id":"c","text":"True, only in PPR"},{"id":"d","text":"False, but only for images"}],"correctAnswerIds":["a"],"explanation":"The shell's job is instant static content. Wrapping ready content in boundaries only delays it behind fallbacks.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: loading.js and Suspense boundaries — placement guidance","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}},"databaseId":"6ab1958db8dd2d82472cb3c9"},{"id":"nextjs-0ec6-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Two panels share one slow fetch; a third is static. Boundary design?","intro":"Placement scenario.","images":[],"followUp":"What covers the shared fetch?","code":"","choices":[{"id":"a","text":"One boundary around the two dependent panels (shared skeleton); static content outside boundaries"},{"id":"b","text":"Three separate boundaries"},{"id":"c","text":"One page-wide boundary"},{"id":"d","text":"No boundaries at all"}],"correctAnswerIds":["a"],"explanation":"Boundaries follow data dependencies: shared dependency → shared boundary. The static panel ships with the shell, no boundary tax.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: loading.js and Suspense boundaries — placement guidance","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}},"databaseId":"6ab1958db8dd2d82472cb3ca"}]},{"id":"6aa2b1d3a7147974707d0ec7","question":"How should errors be handled when only one streamed segment fails?","shortAnswer":"Place error boundaries near independently failing segments so the rest of the page remains usable, provide a reset action, and keep sensitive server error details out of the response.","longAnswer":"Streaming changes error handling from all-or-nothing to per-segment: because the shell and other segments have already been sent, a failed Suspense segment can't produce a page-level 500 — instead its nearest error boundary (the closest error.tsx) renders in place, the rest of the page stays usable, and the failure is isolated visually and functionally. Design accordingly: place error.tsx at meaningful segment scopes (panel-level boundaries so a failed widget shows a retry card, not a dead page), keep boundaries client components with reset (retry) affordances, log segment failures with enough context (segment id, request id) to diagnose, and consider retryability — a transient data failure inside a stream is often best retried by the user clicking retry rather than reloading everything. Server-side, ensure fetch failures inside a suspended segment throw within it, not before the shell flushes.","images":[],"codeSnippets":[{"title":"Panel-level error boundary with retry","language":"tsx","code":"// app/dashboard/reviews/error.tsx — client, segment-scoped\n'use client';\nexport default function ReviewsError({ error, reset }: { error: Error; reset: () => void }) {\n return (\n

Reviews failed to load.

\n {/* re-renders ONLY this segment */}\n

\n );\n}\n\n// app/dashboard/page.tsx — the rest of the page is unaffected\nexport default function Dashboard() {\n return (\n <>\n

{/* already sent, never at risk */}\n }>\n }> {/* may fail alone */}\n \n );\n}"}],"references":[{"title":"Next.js Docs: error.js — segment-scoped error boundaries","url":"https://nextjs.org/docs/app/building-your-application/routing/error-ui"},{"title":"React Docs: error boundaries and streaming SSR","url":"https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary"}],"tips":["The UX tell of good streaming error design: the user never notices the rest of the page. If one widget failure blanks the page, your boundary is too high.","error.tsx must be a client component — it needs reset()/event handlers. The boundary catches render/data errors of ITS segment only."],"challenges":[],"mcqs":[{"id":"nextjs-0ec7-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A streamed reviews segment throws after the shell flushed. What does the user see?","intro":"Streaming error model.","images":[],"followUp":"What does the rest of the page do?","code":"","choices":[{"id":"a","text":"The segment's nearest error boundary UI in place — shell and other segments remain intact"},{"id":"b","text":"A full-page 500"},{"id":"c","text":"Nothing — streaming hides errors"},{"id":"d","text":"An infinite skeleton"}],"correctAnswerIds":["a"],"explanation":"Post-flush failures render into the already-streamed tree at the nearest boundary: isolation, not page failure.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: error.js — segment-scoped error boundaries","url":"https://nextjs.org/docs/app/building-your-application/routing/error-ui"}},"databaseId":"6ab1958cb8dd2d82472cb3c3"},{"id":"nextjs-0ec7-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why must error.tsx be a client component?","intro":"Boundary mechanics.","images":[],"followUp":"What does its reset() do?","code":"","choices":[{"id":"a","text":"It renders interactive recovery (retry via reset()) — server components can't hold handlers"},{"id":"b","text":"Because errors are client-only"},{"id":"c","text":"For SEO reasons"},{"id":"d","text":"It doesn't have to be"}],"correctAnswerIds":["a"],"explanation":"Recovery is interaction: reset() re-renders the segment. That requires the client runtime, hence 'use client'.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: error.js — segment-scoped error boundaries","url":"https://nextjs.org/docs/app/building-your-application/routing/error-ui"}},"databaseId":"6ab1958cb8dd2d82472cb3c4"},{"id":"nextjs-0ec7-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: a segment failure can still be converted into a proper 500 status code.","intro":"Post-flush semantics.","images":[],"followUp":"What has the response already become?","code":"","choices":[{"id":"a","text":"False — once the shell streams with 200, the status is sent; per-segment UI is the only recovery channel"},{"id":"b","text":"True — streaming rewrites status"},{"id":"c","text":"True, on Edge"},{"id":"d","text":"False, but headers reopen"}],"correctAnswerIds":["a"],"explanation":"HTTP status is decided at flush: streamed pages commit to 200 early. This is precisely why boundaries matter more under streaming.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: error.js — segment-scoped error boundaries","url":"https://nextjs.org/docs/app/building-your-application/routing/error-ui"}},"databaseId":"6ab1958cb8dd2d82472cb3c5"},{"id":"nextjs-0ec7-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A transient DB blip fails one widget mid-stream. Best recovery affordance?","intro":"Recovery design.","images":[],"followUp":"What does reset() re-trigger?","code":"","choices":[{"id":"a","text":"A retry button in that widget's error boundary — reset() re-renders just the failed segment"},{"id":"b","text":"location.reload()"},{"id":"c","text":"Nothing — wait for TTL"},{"id":"d","text":"Log out the user"}],"correctAnswerIds":["a"],"explanation":"Segment-scoped reset retries exactly the failed unit: cheap for the user and precise for the server.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: error.js — segment-scoped error boundaries","url":"https://nextjs.org/docs/app/building-your-application/routing/error-ui"}},"databaseId":"6ab1958db8dd2d82472cb3c6"}]},{"id":"6aa2b1d3a7147974707d0ec8","question":"How do route handlers differ from a separate API service in deployment?","shortAnswer":"Route handlers share the Next.js application and deployment concerns, while a separate service has independent scaling, contracts, observability, and runtime boundaries; the frontend should depend on an explicit contract either way.","longAnswer":"Route handlers and a separate API service differ on coupling, scaling, and consumers. Handlers live in the same deploy: no network hop, shared types and auth code, one pipeline — ideal when the only consumer is your own UI and logic is app-shaped. A separate service earns its cost when multiple consumers exist (mobile apps, partners), the team needs independent scaling/deploys, the stack differs (different language/runtime), or long-running/background work doesn't fit serverless function limits. The tradeoffs are operational: a separate service adds a network hop (latency), an auth contract between the tiers, and versioning discipline; handlers couple API evolution to front-end deploys but eliminate cross-tier drift. A common mature shape: handlers as the app's BFF (backend-for-frontend) over a separate domain service.","images":[],"codeSnippets":[{"title":"BFF-shaped handler over a domain service","language":"ts","code":"// app/api/dashboard/route.ts — shapes FOR the UI (BFF)\nexport async function GET() {\n const session = await requireSession();\n // Calls the DOMAIN service (stable contract, independent deploy):\n const [profile, orders] = await Promise.all([\n domainApi.get(`/users/${session.userId}/profile`),\n domainApi.get(`/users/${session.userId}/orders?limit=5`),\n ]);\n const { data: p } = await profile.json();\n const { data: o } = await orders.json();\n\n // UI-shaped response — the client never needs to compose three endpoints:\n return Response.json({\n greeting: `Hi ${p.firstName}`,\n recentOrders: o.map((x) => ({ id: x.id, total: x.total, status: x.status })),\n });\n}\n// domainApi runs as a separate service (own deploys, own scaling, serves\n// mobile too). Handlers = UI contract; service = domain contract."}],"references":[{"title":"Next.js Docs: Route handlers — building your API layer","url":"https://nextjs.org/docs/app/building-your-application/routing/route-handlers"},{"title":"web.dev: Backend-for-frontend pattern overview","url":"https://web.dev/articles/optimizing-long-tasks"}],"tips":["The BFF pattern resolves most debates: route handlers compose/shape for the UI, delegating domain logic to a stable service — UI freedom without API chaos.","The 'shared types' benefit of handlers is real but temporary: the moment a second consumer appears, you'll want an explicit API contract anyway."],"challenges":[],"mcqs":[{"id":"nextjs-0ec8-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"When do route handlers clearly win over a separate API service?","intro":"Fit analysis.","images":[],"followUp":"What do they share?","code":"","choices":[{"id":"a","text":"Single consumer (your UI), app-shaped logic — same deploy, no hop, shared types/auth"},{"id":"b","text":"Many external consumers"},{"id":"c","text":"Long-running jobs"},{"id":"d","text":"Independent scaling needs"}],"correctAnswerIds":["a"],"explanation":"If the UI is the only client, a separate service adds latency and contract overhead without benefit. Handlers keep it one deploy.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Route handlers — building your API layer","url":"https://nextjs.org/docs/app/building-your-application/routing/route-handlers"}},"databaseId":"6ab1958bb8dd2d82472cb3c0"},{"id":"nextjs-0ec8-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which requirement forces a separate service despite handlers being available?","intro":"Forcing function.","images":[],"followUp":"Why can't handlers serve it?","code":"","choices":[{"id":"a","text":"Multiple first-class consumers (mobile/partners) needing a stable contract independent of web deploys"},{"id":"b","text":"Serving JSON"},{"id":"c","text":"Reading from a database"},{"id":"d","text":"Using TypeScript"}],"correctAnswerIds":["a"],"explanation":"Handlers redeploy with the web app — coupling partners/mobile to web release cadence. A stable service decouples consumers.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Route handlers — building your API layer","url":"https://nextjs.org/docs/app/building-your-application/routing/route-handlers"}},"databaseId":"6ab1958bb8dd2d82472cb3c1"},{"id":"nextjs-0ec8-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: route handlers introduce a network hop between your UI and its data.","intro":"Deployment physics.","images":[],"followUp":"Where would that hop exist instead?","code":"","choices":[{"id":"a","text":"False — handlers deploy with the app and are called in-process from server components; a separate service adds the hop"},{"id":"b","text":"True — like any API"},{"id":"c","text":"True, only on Edge"},{"id":"d","text":"True, unless cached"}],"correctAnswerIds":["a"],"explanation":"Server components can import data functions directly (no fetch to self); handlers are for external or client callers. The separate service is where latency appears.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Route handlers — building your API layer","url":"https://nextjs.org/docs/app/building-your-application/routing/route-handlers"}},"databaseId":"6ab1958cb8dd2d82472cb3c2"}]},{"id":"6aa2b1d3a7147974707d0ec9","question":"How do you protect a route handler against forged mutations?","shortAnswer":"Validate the session, authorization, origin or CSRF requirements for cookie-authenticated requests, validate the body, enforce rate limits where needed, and make mutation behavior idempotent when retries are possible.","longAnswer":"A route handler that mutates state must verify the request is genuine: (1) authenticate — session cookies or bearer tokens verified server-side, never trusting client-sent identity fields; (2) authorize — the operation checks permissions, not just presence of a token; (3) anti-CSRF — SameSite=Strict/Lax cookies plus origin checking (compare the Origin/Referer header against the deployment host) for cookie-authenticated POSTs; (4) integrity for webhook-type handlers — verify HMAC signatures (constant-time compare) against the provider's secret before trusting the payload; (5) idempotency — accept client-generated request IDs for retry-safe writes so replays don't double-charge. A 'POST /api/transfer' that works because the browser attaches cookies and the handler trusts the body is the canonical forged-mutation bug.","images":[],"codeSnippets":[{"title":"A hardened mutating handler","language":"ts","code":"$4f"}],"references":[{"title":"OWASP: Cross-Site Request Forgery prevention — SameSite and origin checks","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html"},{"title":"Next.js Docs: Route handlers — securing requests","url":"https://nextjs.org/docs/app/building-your-application/routing/route-handlers"}],"tips":["Origin checking is three lines and kills cross-site POSTs even when cookie policy drifts: request.headers.get('origin') must match your host or the request is rejected.","For webhooks, signature verification comes BEFORE parsing/trusting the body — read the raw body, verify the HMAC, only then parse."],"challenges":[],"mcqs":[{"id":"nextjs-0ec9-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which header comparison defends a cookie-authenticated POST handler against CSRF?","intro":"Origin discipline.","images":[],"followUp":"What happens on mismatch?","code":"","choices":[{"id":"a","text":"Origin (or Referer) must match the deployment host; mismatch = reject with 403"},{"id":"b","text":"User-Agent must be a browser"},{"id":"c","text":"Accept-Language"},{"id":"d","text":"X-Requested-With only"}],"correctAnswerIds":["a"],"explanation":"Forged cross-site posts carry the attacker's origin (or none). Host-matching rejects them regardless of cookie behavior.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Cross-Site Request Forgery prevention — SameSite and origin checks","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html"}},"databaseId":"6ab1958bb8dd2d82472cb3bc"},{"id":"nextjs-0ec9-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A webhook handler parses the JSON body, then checks the signature header. Order problem?","intro":"Webhook integrity.","images":[],"followUp":"What must it verify against?","code":"","choices":[{"id":"a","text":"Verify the HMAC over the RAW body first (against the provider secret), then parse — signature-after-parse trusts unvalidated input"},{"id":"b","text":"None — parsing is harmless"},{"id":"c","text":"Only that it's JSON"},{"id":"d","text":"It should skip signatures"}],"correctAnswerIds":["a"],"explanation":"The signature covers the exact bytes received: read raw → verify (constant-time) → parse. Anything else can be desynced from the signature.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Cross-Site Request Forgery prevention — SameSite and origin checks","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html"}},"databaseId":"6ab1958bb8dd2d82472cb3bd"},{"id":"nextjs-0ec9-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: SameSite=Strict cookies eliminate the need for origin checks on POST handlers.","intro":"Layered CSRF defense.","images":[],"followUp":"Why keep both?","code":"","choices":[{"id":"a","text":"False in spirit — SameSite is the main defense, but browsers/edge cases drift; origin checks are the cheap second layer"},{"id":"b","text":"True — SameSite is complete"},{"id":"c","text":"True, if also Secure"},{"id":"d","text":"False — SameSite doesn't exist"}],"correctAnswerIds":["a"],"explanation":"Defense in depth: cookie policy + origin validation together survive individual misconfigurations or browser quirks.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Cross-Site Request Forgery prevention — SameSite and origin checks","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html"}},"databaseId":"6ab1958bb8dd2d82472cb3be"},{"id":"nextjs-0ec9-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"POST /api/transfer uses client-sent 'userId' from the body as the debit account. Bug class?","intro":"Forged identity scenario.","images":[],"followUp":"What's the fix?","code":"","choices":[{"id":"a","text":"Forged identity — take identity from the verified session, never from request-body fields"},{"id":"b","text":"None — the UI sends it"},{"id":"c","text":"Performance only"},{"id":"d","text":"Missing rate limit"}],"correctAnswerIds":["a"],"explanation":"Anything in the request body is attacker-controlled. The authenticated principal comes from the verified session — nowhere else.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Cross-Site Request Forgery prevention — SameSite and origin checks","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html"}},"databaseId":"6ab1958bb8dd2d82472cb3bf"}]},{"id":"6aa2b1d3a7147974707d0eca","question":"How should middleware and server authorization work together?","shortAnswer":"Middleware can perform cheap early redirects or broad checks, but the authoritative authorization decision must happen next to the protected data or mutation because middleware is not a substitute for resource-level checks.","longAnswer":"Middleware and server-side authorization are complementary layers with different jobs: middleware (Edge, fast, stateless) performs coarse gating — token presence/integrity, routing unauthenticated traffic to login, adding security headers, region-level routing — before the request costs anything; real authorization (who is this, what may they touch) happens in the Node tier where the database lives: server components, Server Actions, and route handlers verify the session store and enforce permissions per operation. Middleware must be understood as neither a security boundary nor a substitute: it executes on Edge (no DB), can be bypassed in misconfigurations, and its checks can go stale. The working contract: middleware rejects obviously-bad traffic cheaply; the operation layer is the authority.","images":[],"codeSnippets":[{"title":"The two-layer contract","language":"ts","code":"// Layer 1: middleware.ts (Edge) — cheap, coarse, stateless\nexport function middleware(request: NextRequest) {\n const hasToken = request.cookies.has('session');\n if (!hasToken && request.nextUrl.pathname.startsWith('/admin')) {\n return NextResponse.redirect(new URL('/login', request.url));\n }\n const res = NextResponse.next();\n res.headers.set('x-request-id', crypto.randomUUID()); // correlation for layer 2\n return res;\n}\n\n// Layer 2: the operation (Node) — the actual boundary\n'use server';\nexport async function grantRole(userId: string, role: Role) {\n const session = await requireRole('owner'); // DB-backed, current, authoritative\n await audit.log({ actor: session.userId, action: 'grantRole', target: userId, role });\n await db.roles.grant(userId, role);\n}\n// Middleware never answers 'may this user do this?' — it only filters the obviously unauthenticated."}],"references":[{"title":"Next.js Docs: Middleware — capabilities and limits","url":"https://nextjs.org/docs/app/building-your-application/routing/middleware"},{"title":"Next.js Docs: Auth with middleware vs data-layer checks","url":"https://nextjs.org/docs/app/building-your-application/authentication#protecting-routes-with-middleware"}],"tips":["Design middleware to answer 'should this request continue at all?' — anything requiring knowledge of the user beyond token validity belongs behind it, not in it.","Log both layers' denials with a shared request ID: the pattern (middleware-pass → operation-deny) is how you spot attacks that skip the UI."],"challenges":[],"mcqs":[{"id":"nextjs-0eca-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What is middleware well-suited for in an auth architecture?","intro":"Layer role.","images":[],"followUp":"What is it NOT for?","code":"","choices":[{"id":"a","text":"Coarse, stateless gating (token integrity, login redirects, headers) — not permission decisions"},{"id":"b","text":"Database-backed role checks"},{"id":"c","text":"Session revocation"},{"id":"d","text":"Audit logging to Postgres"}],"correctAnswerIds":["a"],"explanation":"Edge middleware has no DB and its decisions are cheap pre-checks. Permissions live where identity is resolved against the store.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Middleware — capabilities and limits","url":"https://nextjs.org/docs/app/building-your-application/routing/middleware"}},"databaseId":"6ab1958ab8dd2d82472cb3b8"},{"id":"nextjs-0eca-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why must permission checks still live in Server Actions even with middleware guarding /admin?","intro":"Defense in depth.","images":[],"followUp":"What happens if the action trusts middleware?","code":"","choices":[{"id":"a","text":"Actions are directly invokable — any caller skipping the UI must still be authorized at the operation"},{"id":"b","text":"They shouldn't — middleware covers actions"},{"id":"c","text":"Only for performance"},{"id":"d","text":"Because actions are client-side"}],"correctAnswerIds":["a"],"explanation":"Server Actions are POST endpoints; a crafted request targets them directly. The operation is the boundary; middleware is a filter.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Middleware — capabilities and limits","url":"https://nextjs.org/docs/app/building-your-application/routing/middleware"}},"databaseId":"6ab1958ab8dd2d82472cb3b9"},{"id":"nextjs-0eca-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: a middleware that checks the session cookie's JWT signature is a sufficient security boundary.","intro":"Boundary semantics.","images":[],"followUp":"What can it not know?","code":"","choices":[{"id":"a","text":"False — signature ≠ current authorization (revocation, role changes); the store-backed check is authoritative"},{"id":"b","text":"True — signatures are enough"},{"id":"c","text":"True, if HS256"},{"id":"d","text":"False — middleware can't verify signatures"}],"correctAnswerIds":["a"],"explanation":"A valid-but-stale token passes signature checks: revoked sessions and downgraded roles need the live store — the operation's job.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Middleware — capabilities and limits","url":"https://nextjs.org/docs/app/building-your-application/routing/middleware"}},"databaseId":"6ab1958ab8dd2d82472cb3ba"},{"id":"nextjs-0eca-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Traffic shows requests skipping UI entirely, hitting Server Actions with valid tokens but no permission. Which layer stopped it?","intro":"Attack scenario.","images":[],"followUp":"What did middleware correctly do?","code":"","choices":[{"id":"a","text":"The operation layer (action's authorization) — middleware passed them since tokens were authentic"},{"id":"b","text":"Middleware blocked them"},{"id":"c","text":"The CDN"},{"id":"d","text":"Nobody — it succeeded"}],"correctAnswerIds":["a"],"explanation":"This is exactly the designed division: middleware can't know permissions, operations can. The layered design absorbed the attack.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Middleware — capabilities and limits","url":"https://nextjs.org/docs/app/building-your-application/routing/middleware"}},"databaseId":"6ab1958ab8dd2d82472cb3bb"}]},{"id":"6aa2b1d3a7147974707d0ecb","question":"How do you implement role-aware metadata without leaking private information?","shortAnswer":"Generate metadata from authorized server data, return generic metadata for unauthorized states, and avoid embedding private identifiers or sensitive content into public HTML or social previews.","longAnswer":"Metadata is content, not chrome: title/description/OG output can carry role-derived data into HTML that gets cached (Full Route Cache, CDN), shared (link previews render it for anyone), or logged — so generating per-user personalized metadata for shared URLs leaks by construction. The design rule: metadata describes the RESOURCE, not the viewer — a shared page's metadata stays identical regardless of who's logged in; personalization lives in the streamed body inside protected segments. When role genuinely must affect metadata (e.g., an admin's document title on a private dashboard), that metadata belongs on genuinely private, no-store, non-cached routes where the HTML head never leaves the session's own response. Never place secrets (tokens, emails, internal names) in metadata — head content is also exactly what scrapers and preview bots read first.","images":[],"codeSnippets":[{"title":"Resource-level metadata, body-level personalization","language":"tsx","code":"// app/admin/billing/page.tsx — PRIVATE route (no-store, session-gated)\nexport const dynamic = 'force-dynamic';\nexport const metadata = { title: 'Billing — Admin' }; // resource-level, no user data\n\nexport default async function BillingPage() {\n const session = await requireRole('billing-admin');\n return (\n <>\n

Welcome back, {session.user.name}

{/* body: personalized safely */}\n \n \n );\n}\n\n// ❌ generateMetadata({ session }) → title: `Billing — ${session.user.name}`\n// Even on private routes this is fragile: any future cache/prefetch layer\n// re-introduces the leak. Keep names in the body where sessions belong."}],"references":[{"title":"Next.js Docs: Metadata caching — what gets prerendered","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata#caching"},{"title":"web.dev: Open Graph and social previews — public head content","url":"https://web.dev/articles/optimize-lcp"}],"tips":["OG images and titles get rendered by chat apps and scrapers to ANYONE with the URL — that's the mental model: metadata is public until proven otherwise.","If generateMetadata's output would change per session, either the route should be private/no-store, or the personalization belongs in the body, not the head."],"challenges":[],"mcqs":[{"id":"nextjs-0ecb-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"generateMetadata returns 'Acme Corp — John Doe's admin panel' on a shared URL. Risk?","intro":"Leak path.","images":[],"followUp":"Where does the content end up?","code":"","choices":[{"id":"a","text":"The name is cached/served to other users and link previews — head content is shared content"},{"id":"b","text":"None — head is per-user"},{"id":"c","text":"Only a hydration warning"},{"id":"d","text":"A build error"}],"correctAnswerIds":["a"],"explanation":"Head output is cached and rendered by preview bots for whoever holds the URL — any session-derived value becomes public.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Metadata caching — what gets prerendered","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata#caching"}},"databaseId":"6ab19589b8dd2d82472cb3b4"},{"id":"nextjs-0ecb-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which principle keeps metadata safe?","intro":"Design rule.","images":[],"followUp":"Where does personalization go?","code":"","choices":[{"id":"a","text":"Metadata describes the resource, not the viewer — personalization lives in the protected body"},{"id":"b","text":"Metadata must be encrypted"},{"id":"c","text":"Metadata should be client-rendered"},{"id":"d","text":"Metadata must include the role"}],"correctAnswerIds":["a"],"explanation":"One shared URL gets one head. Viewer-specific rendering happens in the streamed, authorized body — never in cacheable head tags.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Metadata caching — what gets prerendered","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata#caching"}},"databaseId":"6ab19589b8dd2d82472cb3b5"},{"id":"nextjs-0ecb-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: a private dashboard's personalized title is safe if the route is force-dynamic with no-store.","intro":"Private-route exception.","images":[],"followUp":"What condition makes it acceptable?","code":"","choices":[{"id":"a","text":"True — as long as nothing caches the response; the head exists only in that user's response"},{"id":"b","text":"False — heads are always public"},{"id":"c","text":"True, on any route"},{"id":"d","text":"False — titles can't be personalized"}],"correctAnswerIds":["a"],"explanation":"The risk was caching/sharing, not the head itself. A genuinely private (no-store, authorized) response may personalize its head safely.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Metadata caching — what gets prerendered","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata#caching"}},"databaseId":"6ab1958ab8dd2d82472cb3b6"},{"id":"nextjs-0ecb-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"An OG image generation includes the logged-in user's avatar on a public product page. Problem?","intro":"Preview scenario.","images":[],"followUp":"What's the fix?","code":"","choices":[{"id":"a","text":"Preview bots fetch the OG image without sessions — use product imagery, not viewer-specific content"},{"id":"b","text":"None — avatars are public"},{"id":"c","text":"OG images must be SVG"},{"id":"d","text":"Only affects iOS"}],"correctAnswerIds":["a"],"explanation":"Link previews render for third parties: the 'viewer' at OG-render time is a bot, not your user. Resource-level imagery only.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Metadata caching — what gets prerendered","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata#caching"}},"databaseId":"6ab1958ab8dd2d82472cb3b7"}]},{"id":"6aa2b1d3a7147974707d0ecc","question":"How do you secure authentication redirects in Next.js?","shortAnswer":"Validate callback and return URLs as same-origin paths or strict allowlisted origins, normalize them, and never redirect to arbitrary user-provided absolute URLs.","longAnswer":"Authentication redirects are an open-redirect surface the moment any part of the target comes from the request (query param like ?next=, referer, stored return URL). The unvalidated version happily sends users to attacker-hosted lookalike pages post-login. The secure pattern: treat redirect targets as untrusted input — accept only relative paths (reject scheme-relative //evil.com, embedded credentials, and absolute URLs), validate against an allowlist of path prefixes when flows are route-specific, encode the target once (encodeURIComponent) and decode once at use, and prefer server-side redirect() with the validated value over client-constructed URLs. For OAuth flows, the state parameter (signed, nonce-bound) carries the return path so it can't be forged, and the callback validates it before redirecting.","images":[],"codeSnippets":[{"title":"A hardened redirect validator","language":"ts","code":"$50"}],"references":[{"title":"OWASP: Unvalidated Redirects and Forwards cheat sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"},{"title":"Auth.js Docs: callback redirect — allowlisted redirect URLs","url":"https://authjs.dev/reference/core/errors#redirect"}],"tips":["The minimal correct validator: target must start with '/' AND not start with '//' — that single pair of checks kills absolute and scheme-relative redirects.","Carry return paths through OAuth 'state' (signed), not through free-form callback URLs — the state round-trip is what makes it tamper-evident."],"challenges":[],"mcqs":[{"id":"nextjs-0ecc-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which redirect target is dangerous if accepted verbatim?","intro":"Threat recognition.","images":[],"followUp":"Why is it dangerous?","code":"","choices":[{"id":"a","text":"https://evil.example/login — post-auth redirect to an attacker-controlled page"},{"id":"b","text":"/dashboard"},{"id":"c","text":"/account?tab=2"},{"id":"d","text":"#settings"}],"correctAnswerIds":["a"],"explanation":"Absolute URLs to other origins are the classic open redirect: your login page becomes a phishing delivery mechanism.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Unvalidated Redirects and Forwards cheat sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"}},"databaseId":"6ab19588b8dd2d82472cb3af"},{"id":"nextjs-0ecc-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What does the check 'startsWith(\"/\") && !startsWith(\"//\")' accomplish?","intro":"Validator logic.","images":[],"followUp":"What does the second condition reject?","code":"","choices":[{"id":"a","text":"Allows only same-origin relative paths — rejecting absolute URLs and scheme-relative '//evil.com'"},{"id":"b","text":"Blocks all redirects"},{"id":"c","text":"Allows only HTTPS"},{"id":"d","text":"Blocks query strings"}],"correctAnswerIds":["a"],"explanation":"Scheme-relative URLs (//host) are absolute in disguise and browsers treat them as different origins — the second check closes that hole.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Unvalidated Redirects and Forwards cheat sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"}},"databaseId":"6ab19588b8dd2d82472cb3b0"},{"id":"nextjs-0ecc-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: the ?next= parameter should be trusted if it came from your own link.","intro":"Trust boundaries.","images":[],"followUp":"Why not?","code":"","choices":[{"id":"a","text":"False — anyone can craft the link (emails, ads, other sites); validate at the redirect point regardless of origin"},{"id":"b","text":"True — you generated it"},{"id":"c","text":"True, over HTTPS"},{"id":"d","text":"True, if URL-encoded"}],"correctAnswerIds":["a"],"explanation":"Attackers phish with your own login URL plus a poisoned next=. Validation lives at the point of use, not at the point of link creation.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Unvalidated Redirects and Forwards cheat sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"}},"databaseId":"6ab19588b8dd2d82472cb3b1"},{"id":"nextjs-0ecc-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"OAuth callback receives state=... and next=... . Which carries the return path?","intro":"OAuth flow design.","images":[],"followUp":"What makes state tamper-evident?","code":"","choices":[{"id":"a","text":"state — it's signed/nonce-bound by your server; validate it before honoring any redirect"},{"id":"b","text":"next — it's simpler"},{"id":"c","text":"Both equally"},{"id":"d","text":"Neither — return paths are lost"}],"correctAnswerIds":["a"],"explanation":"state round-trips through the provider with your signature on it; free-form query params have no such guarantee and must be re-validated anyway.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Unvalidated Redirects and Forwards cheat sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"}},"databaseId":"6ab19589b8dd2d82472cb3b2"},{"id":"nextjs-0ecc-5","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A security review finds login?next=%2F%2Fevil.com passes validation that checks startsWith('/'). Why?","intro":"Encoding scenario.","images":[],"followUp":"Where does decoding happen?","code":"","choices":[{"id":"a","text":"The value decodes to '//evil.com' (scheme-relative) — decode once at use, then validate the decoded value"},{"id":"b","text":"It doesn't — %2F blocks it"},{"id":"c","text":"Because HTTPS strips %2F"},{"id":"d","text":"It's a false positive"}],"correctAnswerIds":["a"],"explanation":"Percent-encoded payloads bypass naive checks: decode first, then apply the '/' + not-'//' rule to the decoded string.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"OWASP: Unvalidated Redirects and Forwards cheat sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"}},"databaseId":"6ab19589b8dd2d82472cb3b3"}]},{"id":"6aa2b1d3a7147974707d0ecd","question":"How do you handle session expiry in a mixed Server and Client Component tree?","shortAnswer":"Let server operations return an unauthenticated result or redirect, keep client state resilient to expiration, clear stale private data, and retry only after an explicit session refresh or sign-in flow.","longAnswer":"Session expiry in a mixed tree fails differently per layer: server components hitting an expired session should redirect (not render broken UI), Server Actions should throw a typed error that surfaces as a redirect or a re-auth prompt, and client islands calling APIs on expiry need a wrapper that recognizes 401 and either refreshes the session (rotation endpoint) or hard-redirects to login — silently rendering 'loading forever' is the UX failure to avoid. The mechanics: server-side expiry detection is authoritative (the cookie may claim validity the store disagrees with); client-side proactive refresh (rotating before expiry via a timer) prevents most visible failures; and every expired-session path must end in ONE canonical behavior — redirect to login with a return URL — so users never land in a half-authenticated tree.","images":[],"codeSnippets":[{"title":"One canonical expiry behavior","language":"ts","code":"// lib/session-client.ts — every client island imports this\nexport async function apiFetch(input: RequestInfo, init?: RequestInit) {\n const res = await fetch(input, init);\n if (res.status === 401) {\n const refreshed = await fetch('/api/auth/refresh', { method: 'POST' });\n if (refreshed.ok) return fetch(input, init); // transparent retry\n const next = encodeURIComponent(location.pathname + location.search);\n location.assign(`/login?next=${encodeURIComponent(next)}`); // canonical redirect\n throw new Error('session-expired');\n }\n return res;\n}\n\n// lib/session-server.ts — every server component/action imports this\nexport async function requireSession() {\n const session = await getSession(); // store-backed, authoritative\n if (!session) redirect(`/login?next=${encodeURIComponent(currentPath())}`);\n return session;\n}"}],"references":[{"title":"Next.js Docs: redirect — server-side navigation on expiry","url":"https://nextjs.org/docs/app/api-reference/functions/redirect"},{"title":"Auth.js Docs: handling session expiration and refresh","url":"https://authjs.dev/concepts/session-management"}],"tips":["Centralize the 401 story: one fetch wrapper used by every client island, one requireSession() used by every server component/action — two functions, one behavior.","Return URLs after re-auth need the same redirect validation as login (relative-only) — expiry flows inherit open-redirect risk."],"challenges":[],"mcqs":[{"id":"nextjs-0ecd-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A server component detects an expired session mid-render. Correct behavior?","intro":"Server-side expiry.","images":[],"followUp":"Which function implements it?","code":"","choices":[{"id":"a","text":"redirect('/login?next=…') — never render the protected tree on a dead session"},{"id":"b","text":"Render a 'session expired' div"},{"id":"c","text":"Return null"},{"id":"d","text":"Throw a 500"}],"correctAnswerIds":["a"],"explanation":"Expiry is an expected state with a known response: send the user to re-auth carrying where they were — deterministically.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: redirect — server-side navigation on expiry","url":"https://nextjs.org/docs/app/api-reference/functions/redirect"}},"databaseId":"6ab19588b8dd2d82472cb3ab"},{"id":"nextjs-0ecd-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A client island's fetch gets 401. What prevents the 'silent stuck spinner' failure?","intro":"Client-side expiry.","images":[],"followUp":"Where does the wrapper live?","code":"","choices":[{"id":"a","text":"A shared fetch wrapper that catches 401 and redirects to login (or attempts refresh first)"},{"id":"b","text":"Infinite retry"},{"id":"c","text":"localStorage token caching"},{"id":"d","text":"Browser alert"}],"correctAnswerIds":["a"],"explanation":"Every island funnels through one wrapper: 401 → refresh attempt → canonical redirect. No bespoke per-component handling to forget.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: redirect — server-side navigation on expiry","url":"https://nextjs.org/docs/app/api-reference/functions/redirect"}},"databaseId":"6ab19588b8dd2d82472cb3ac"},{"id":"nextjs-0ecd-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: the session cookie alone is proof the session is still valid.","intro":"Trust model.","images":[],"followUp":"What's the authoritative check?","code":"","choices":[{"id":"a","text":"False — the cookie may be expired/revoked while present; the server-side session store is authoritative"},{"id":"b","text":"True — cookies are signed"},{"id":"c","text":"True for JWT cookies"},{"id":"d","text":"False, but JWTs prove validity"}],"correctAnswerIds":["a"],"explanation":"Revocation, logout-everywhere, and rotation all invalidate sessions the cookie still 'contains'. The store (or verified short-TTL JWT) decides.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: redirect — server-side navigation on expiry","url":"https://nextjs.org/docs/app/api-reference/functions/redirect"}},"databaseId":"6ab19588b8dd2d82472cb3ad"},{"id":"nextjs-0ecd-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Users complain about being dropped to login mid-edit, losing work. Design improvement?","intro":"UX failure scenario.","images":[],"followUp":"What happens client-side before redirect?","code":"","choices":[{"id":"a","text":"Proactive refresh before expiry (timer/refresh-on-visibility) plus 401-wrapped requests that preserve state into the re-auth flow"},{"id":"b","text":"Longer cookie lifetime only"},{"id":"c","text":"Disable expiry"},{"id":"d","text":"Poll the server every second"}],"correctAnswerIds":["a"],"explanation":"Refresh-before-expiry avoids the surprise; when re-auth is unavoidable, carrying return URL + draft state keeps the loss minimal.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: redirect — server-side navigation on expiry","url":"https://nextjs.org/docs/app/api-reference/functions/redirect"}},"databaseId":"6ab19588b8dd2d82472cb3ae"}]},{"id":"6aa2b1d3a7147974707d0ece","question":"What are the risks of doing authentication checks only in layouts?","shortAnswer":"A layout check may not protect every direct data access or route handler, and cached or separately rendered segments can have different boundaries; enforce identity and authorization at the operation that returns protected data.","longAnswer":"Layouts are the wrong single point of truth for authorization because their execution doesn't cover the access surface: navigations between sibling routes under the same layout don't re-run the layout (soft-nav staleness), layouts don't execute for route handlers or Server Actions at all, cached/prerendered outputs may outlive the check that produced them, and layout checks say nothing about the data-layer operations an attacker can hit directly. The result is a check that defends the UI shape but not the resource. The architecture answer is defense in depth: layouts may render a fast provisional shell, but every data fetch, action, and handler re-verifies authorization at the operation; treat layout checks as UX (fast redirect to login), never as the security boundary.","images":[],"codeSnippets":[{"title":"Operation-level authorization, everywhere","language":"ts","code":"// lib/auth.ts — the ONE boundary used by every entry point\nimport { cache } from 'react';\nexport const requireRole = cache(async (role: Role) => {\n const session = await getSession(); // DB-backed, verified\n if (!session) throw new AuthError('unauthenticated');\n if (!session.roles.includes(role)) throw new AuthError('forbidden');\n return session;\n});\n\n// Server Action — checks even though the UI 'hides' it\n'use server';\nexport async function deleteUser(id: string) {\n const { userId } = await requireRole('admin');\n await db.user.delete({ where: { id } });\n revalidatePath('/admin/users');\n}\n\n// Route handler — same boundary, no layout involved\nexport async function GET() {\n const { userId } = await requireRole('admin');\n return Response.json(await exportData(userId));\n}\n// Layout check remains purely as fast UX redirect — never the gate."}],"references":[{"title":"Next.js Docs: Authenticated layouts — guidance and caveats","url":"https://nextjs.org/docs/app/building-your-application/routing/layouts#authentication"},{"title":"OWASP: Authorization — deny by default at the operation","url":"https://owasp.org/www-project-top-ten/2021/A01_2021-Broken_Access_Control/"}],"tips":["Audit question for reviews: 'if I curl this endpoint/action directly, bypassing all UI, is it still authorized?' If the answer lives only in a layout, it's no.","Parallel routes and route groups can render multiple layouts for one URL — an auth check in one of them doesn't cover the others."],"challenges":[],"mcqs":[{"id":"nextjs-0ece-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why is a layout-level auth check insufficient by itself?","intro":"Coverage gaps.","images":[],"followUp":"What surface does it miss entirely?","code":"","choices":[{"id":"a","text":"It doesn't run for route handlers/Server Actions and may not re-run on soft navigation — data ops stay unprotected"},{"id":"b","text":"Layouts can't read cookies"},{"id":"c","text":"Layout checks are deprecated"},{"id":"d","text":"It's sufficient — no gap"}],"correctAnswerIds":["a"],"explanation":"The attacker's path is the direct one: POST to the action or GET the handler. UI-shape checks never execute there — the operation must check.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Authenticated layouts — guidance and caveats","url":"https://nextjs.org/docs/app/building-your-application/routing/layouts#authentication"}},"databaseId":"6ab19587b8dd2d82472cb3a6"},{"id":"nextjs-0ece-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"User navigates from /admin/users to /admin/settings. Does /admin/layout's check re-run?","intro":"Soft-nav behavior.","images":[],"followUp":"What does this imply for the check?","code":"","choices":[{"id":"a","text":"Not necessarily — same-layout sibling navigation can skip layout re-execution; permissions may be stale"},{"id":"b","text":"Always — layouts run every navigation"},{"id":"c","text":"Never — layouts run once per deploy"},{"id":"d","text":"Only on hard refresh"}],"correctAnswerIds":["a"],"explanation":"Layouts persist across sibling navigations — that's their caching benefit and their authorization liability. Operations re-check.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Authenticated layouts — guidance and caveats","url":"https://nextjs.org/docs/app/building-your-application/routing/layouts#authentication"}},"databaseId":"6ab19587b8dd2d82472cb3a7"},{"id":"nextjs-0ece-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: defense in depth means keeping layout checks AND checking authorization at every data operation.","intro":"Architecture principle.","images":[],"followUp":"What role does the layout check play?","code":"","choices":[{"id":"a","text":"True — layout checks are fast UX (redirect early); the operation is the actual boundary"},{"id":"b","text":"False — one layer suffices"},{"id":"c","text":"False — layout checks ARE the boundary"},{"id":"d","text":"True, but only for admin routes"}],"correctAnswerIds":["a"],"explanation":"Layers serve different purposes: the layout gives instant UX feedback; the operation enforces security regardless of entry path.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Authenticated layouts — guidance and caveats","url":"https://nextjs.org/docs/app/building-your-application/routing/layouts#authentication"}},"databaseId":"6ab19587b8dd2d82472cb3a8"},{"id":"nextjs-0ece-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"An API route /api/admin/export reads only the cookie's role claim to authorize. Threat?","intro":"Direct-access scenario.","images":[],"followUp":"What's the fix?","code":"","choices":[{"id":"a","text":"Forged/stale claims authorize — verify the session server-side (and DB-backed role) inside the handler"},{"id":"b","text":"None — cookies are signed"},{"id":"c","text":"Only XSS risk"},{"id":"d","text":"The route is fine"}],"correctAnswerIds":["a"],"explanation":"If the role comes from a client-visible token claim without server validation, escalation is forgery or staleness away. Resolve roles where they're trusted.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Authenticated layouts — guidance and caveats","url":"https://nextjs.org/docs/app/building-your-application/routing/layouts#authentication"}},"databaseId":"6ab19587b8dd2d82472cb3a9"},{"id":"nextjs-0ece-5","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Parallel routes @modal and @page render under one layout. The check lives in @page. Gap?","intro":"Parallel-route scenario.","images":[],"followUp":"Where must checks also exist?","code":"","choices":[{"id":"a","text":"@modal renders without @page's check — authorize in the shared parent or in each slot's data ops"},{"id":"b","text":"None — slots share checks"},{"id":"c","text":"Only SEO"},{"id":"d","text":"Parallel routes are client-only"}],"correctAnswerIds":["a"],"explanation":"Slots are independent render targets: a check in one doesn't guard another. The operation-level check covers every entry path.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Authenticated layouts — guidance and caveats","url":"https://nextjs.org/docs/app/building-your-application/routing/layouts#authentication"}},"databaseId":"6ab19587b8dd2d82472cb3aa"}]},{"id":"6aa2b1d3a7147974707d0ecf","question":"How do Edge runtime limitations affect Next.js architecture?","shortAnswer":"Edge code favors web-standard APIs and small dependencies, so Node-only libraries, native modules, filesystem access, and some database clients may require a Node runtime or a separate service.","longAnswer":"Edge runtime constraints shape architecture rather than blocking it: no Node APIs means libraries built on fs, net, or native modules (most ORMs with engines, sharp, many auth SDKs) simply don't execute there — those workloads move to a Node runtime route or a separate service, with the Edge function calling them over HTTP. Long-lived state is impossible (short-lived isolates): no warm connection pools, no in-process caches — state externalizes to Data Cache, KV stores, or the Node tier. Small bundle budgets mean heavyweight dependencies blow deployment limits. The resulting architecture is a deliberate split: globally-placed lightweight Edge functions for latency-sensitive policy/token work, Node services for ecosystem-heavy work, connected by explicit HTTP contracts.","images":[],"codeSnippets":[{"title":"Edge fast path + Node data tier","language":"ts","code":"// app/api/whoami/route.ts — EDGE: stateless, web-crypto, fast everywhere\nexport const runtime = 'edge';\nexport async function GET(request: Request) {\n const token = request.cookies.get('session')?.value ?? '';\n const payload = await verifyJwtWebCrypto(token); // Web Crypto only\n if (!payload) return Response.json({ user: null });\n\n // Session DETAILS live in Node-land; fetch them over an internal contract:\n const res = await fetch(`${process.env.INTERNAL_API}/users/${payload.sub}/profile`, {\n headers: { authorization: `Internal ${process.env.INTERNAL_KEY}` },\n cache: 'no-store',\n });\n return Response.json({ user: await res.json() });\n}\n// INTERNAL_API runs on the Node runtime (or a separate service) where\n// Prisma/Postgres/auth SDKs work without Edge constraints."}],"references":[{"title":"Next.js Docs: Edge runtime — unsupported APIs","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes#unsupported-apis"},{"title":"Next.js Docs: Middleware and Edge constraints","url":"https://nextjs.org/docs/app/building-your-application/routing/middleware#runtime"}],"tips":["The compat check belongs in CI: build your Edge-targeted routes with Edge runtime forced, and let the bundler list every Node-API import that breaks — before deploy day.","When an ORM can't go Edge, the pattern is an internal Node route handler (or microservice) the Edge function calls — keep the contract narrow and authenticated."],"challenges":[],"mcqs":[{"id":"nextjs-0ecf-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A Prisma setup using the Rust engine hits an Edge route. What happens?","intro":"Compat reality.","images":[],"followUp":"What's the architectural fix?","code":"","choices":[{"id":"a","text":"It fails — the engine needs Node; use an HTTP-based driver or call a Node service over HTTP"},{"id":"b","text":"It runs slower"},{"id":"c","text":"It silently falls back to REST"},{"id":"d","text":"It works in production only"}],"correctAnswerIds":["a"],"explanation":"Native binaries don't load in isolates. The standard split: Edge for the fast path, a Node tier (or Edge-driver) for the data layer.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Edge runtime — unsupported APIs","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes#unsupported-apis"}},"databaseId":"6ab1957eb8dd2d82472cb372"},{"id":"nextjs-0ecf-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why can't an Edge function hold a database connection pool across requests?","intro":"Lifecycle model.","images":[],"followUp":"Where does shared state go?","code":"","choices":[{"id":"a","text":"Isolates are short-lived and may be discarded anytime — no warm in-process state survives"},{"id":"b","text":"Edge forbids networking"},{"id":"c","text":"Pools need TLS 1.3"},{"id":"d","text":"It can, with keep-alive"}],"correctAnswerIds":["a"],"explanation":"Per-request lifecycle is the cost of instant cold starts. State externalizes: caches, KV, or per-request HTTP connections.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Edge runtime — unsupported APIs","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes#unsupported-apis"}},"databaseId":"6ab1957eb8dd2d82472cb373"},{"id":"nextjs-0ecf-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: Edge functions support the full npm ecosystem if tree-shaken well.","intro":"Ecosystem boundary.","images":[],"followUp":"What determines compatibility?","code":"","choices":[{"id":"a","text":"False — compatibility depends on which APIs a library calls, not bundle size"},{"id":"b","text":"True — it's all JavaScript"},{"id":"c","text":"True, with esbuild"},{"id":"d","text":"False — Edge has no npm"}],"correctAnswerIds":["a"],"explanation":"A tiny library using node:fs is incompatible; a large one using pure web APIs is fine. The API surface, not the size, decides.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Edge runtime — unsupported APIs","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes#unsupported-apis"}},"databaseId":"6ab1957eb8dd2d82472cb374"},{"id":"nextjs-0ecf-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Auth token verification must run in every region with sub-10ms overhead, but sessions live in Postgres. Architecture?","intro":"Split scenario.","images":[],"followUp":"What does the Edge function do on a JWT cache miss?","code":"","choices":[{"id":"a","text":"Edge verifies JWT signatures (Web Crypto) globally; session lookups go to a Node service/API over HTTP"},{"id":"b","text":"Move Postgres to Edge"},{"id":"c","text":"Do everything in Node"},{"id":"d","text":"Skip verification at the edge"}],"correctAnswerIds":["a"],"explanation":"Stateless crypto at the edge + stateful lookups behind an authenticated internal API: each tier does what its runtime is good at.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Edge runtime — unsupported APIs","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes#unsupported-apis"}},"databaseId":"6ab1957eb8dd2d82472cb375"}]},{"id":"6aa2b1d3a7147974707d0ed0","question":"How do you choose runtime placement for authentication?","shortAnswer":"Place verification where required crypto and identity libraries are supported, secrets are available, and latency is acceptable; lightweight token checks can fit Edge while complex session or database work may fit Node.","longAnswer":"Auth runtime placement follows the statefulness rule: stateless token work (JWT signature verification, cookie checks, coarse redirects) fits the Edge runtime — Web Crypto is enough and global placement wins latency; stateful session work (session lookups in a database, permission queries, anything using Node-only SDKs like Prisma's engine) must run in the Node runtime. The practical split: middleware (Edge) validates token integrity and routes unauthenticated traffic fast, near the user; the Node tier does session resolution, role checks, and refresh rotation against the database. Trying to force either way costs: DB clients on Edge break (no Node APIs, no pooled connections), while putting coarse checks on Node adds a region hop to every request that a signature check would have answered locally.","images":[],"codeSnippets":[{"title":"Edge-gate + Node-resolve split","language":"tsx","code":"// middleware.ts — EDGE: fast, stateless gate\nimport { NextResponse } from 'next/server';\nimport type { NextRequest } from 'next/server';\n\nexport async function middleware(request: NextRequest) {\n const token = request.cookies.get('session')?.value;\n if (!token || !(await verifyJwtWebCrypto(token))) {\n return NextResponse.redirect(new URL('/login', request.url));\n }\n return NextResponse.next(); // token is authentic — routing may proceed\n}\n\n// app/dashboard/layout.tsx — NODE: stateful resolution\nimport { auth } from '@/lib/auth'; // Prisma + session store\nexport default async function DashboardLayout({ children }) {\n const session = await auth(); // DB lookup, role resolution, refresh rotation\n if (!session) redirect('/login');\n return {children};\n}"}],"references":[{"title":"Next.js Docs: Edge and Node.js runtimes — choosing","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes"},{"title":"Next.js Docs: Middleware runtime constraints","url":"https://nextjs.org/docs/app/building-your-application/routing/middleware#runtime"}],"tips":["Test the split with one question per task: 'does this need the database, or just the token?' Token = Edge; database = Node.","Refresh-token rotation is stateful by definition (it must revoke previous tokens) — keep it in the Node tier even when verification is Edge-side."],"challenges":[],"mcqs":[{"id":"nextjs-0ed0-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"JWT signature verification in middleware — which runtime and why?","intro":"Placement logic.","images":[],"followUp":"What API does it use?","code":"","choices":[{"id":"a","text":"Edge — it's stateless crypto via Web Crypto, and global placement minimizes latency"},{"id":"b","text":"Node — crypto needs Node"},{"id":"c","text":"Either — verification is region-locked"},{"id":"d","text":"Neither — client-side only"}],"correctAnswerIds":["a"],"explanation":"Verification needs the public key (or secret) and Web Crypto — no database, no Node APIs. Edge runs it everywhere at once.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Edge and Node.js runtimes — choosing","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes"}},"databaseId":"6ab19586b8dd2d82472cb3a3"},{"id":"nextjs-0ed0-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Session lookup requires querying Postgres per request. Runtime?","intro":"Stateful constraint.","images":[],"followUp":"What breaks on Edge?","code":"","choices":[{"id":"a","text":"Node — database access needs Node APIs/pooled connections that Edge isolates can't host"},{"id":"b","text":"Edge — it's faster"},{"id":"c","text":"Client — sessions are client-side"},{"id":"d","text":"Static generation"}],"correctAnswerIds":["a"],"explanation":"Stateful lookups live where the data tier is reachable and connections can be pooled: the Node runtime (or an internal service).","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Edge and Node.js runtimes — choosing","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes"}},"databaseId":"6ab19586b8dd2d82472cb3a4"},{"id":"nextjs-0ed0-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: middleware on Edge can safely hold a connection pool to the database.","intro":"Lifecycle constraint.","images":[],"followUp":"What's the pattern instead?","code":"","choices":[{"id":"a","text":"False — isolates are short-lived and discarded; pools can't persist. Use HTTP calls to a Node tier"},{"id":"b","text":"True — pools are global"},{"id":"c","text":"True with keep-alive"},{"id":"d","text":"False, but it can hold connections briefly"}],"correctAnswerIds":["a"],"explanation":"Per-request lifecycle kills in-process pools. The Edge tier either does stateless work or calls a Node service over HTTP.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Edge and Node.js runtimes — choosing","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes"}},"databaseId":"6ab19587b8dd2d82472cb3a5"}]},{"id":"6aa2b1d3a7147974707d0ed1","question":"How do you optimize Next.js image delivery for Core Web Vitals?","shortAnswer":"Identify the actual LCP image, reserve dimensions, serve an appropriate responsive variant, prioritize only that critical image, lazy-load below-fold media, and verify the result in field and lab measurements.","longAnswer":"next/image turns image delivery into a Core Web Vitals system: it serves responsive variants (srcset across device sizes), modern formats (AVIF/WebP by content negotiation), lazy-loads by default (only above-fold images should opt out with priority), reserves aspect-ratio space via width/height (killing the largest CLS source), and optimizes/encodes on the fly (with a loader/CDN at scale). The LCP-critical hero gets priority (preload + fetchpriority) and explicit sizes; everything below the fold stays lazy. The two failure modes are developer-controlled: omitting width/height (CLS returns) and marking too many images priority (bandwidth contention delays the true LCP). At scale, remotePatterns allowlisting + a dedicated image CDN keep the optimizer off your app server's critical path.","images":[],"codeSnippets":[{"title":"Hero with priority + responsive grid","language":"tsx","code":"import Image from 'next/image';\n\nexport function ProductPage({ product }) {\n return (\n <>\n {/* LCP element: priority + explicit dimensions */}\n \n\n {/* Everything else: lazy by default, responsive via sizes */}\n

\n {product.gallery.map((g) => (\n {g.alt}

\n ))}\n

\n \n );\n}\n// next.config: remotePatterns allowlist for external hosts\n// images: { remotePatterns: [{ protocol: 'https', hostname: 'cdn.acme.com' }] }"}],"references":[{"title":"Next.js Docs: next/image — optimization and priority","url":"https://nextjs.org/docs/app/api-reference/components/image"},{"title":"web.dev: Serve responsive images and optimize LCP","url":"https://web.dev/articles/optimize-lcp"}],"tips":["priority on exactly one image per page — the LCP element. Two preloads fight for the same bandwidth and both lose.","Always pass width/height (or fill for positioned images): without intrinsic dimensions, the browser reserves no space and every image load becomes a layout shift."],"challenges":[],"mcqs":[{"id":"nextjs-0ed1-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which prop marks an above-the-fold hero image as the LCP candidate?","intro":"LCP handling.","images":[],"followUp":"What does it trigger?","code":"","choices":[{"id":"a","text":"priority — preloads the image with fetchpriority=high"},{"id":"b","text":"loading='eager'"},{"id":"c","text":"quality={100}"},{"id":"d","text":"preload"}],"correctAnswerIds":["a"],"explanation":"priority wires preload + fetchpriority so the browser starts the LCP fetch before layout completes.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: next/image — optimization and priority","url":"https://nextjs.org/docs/app/api-reference/components/image"}},"databaseId":"6ab19586b8dd2d82472cb39f"},{"id":"nextjs-0ed1-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"How does next/image prevent image-caused CLS?","intro":"CLS mechanics.","images":[],"followUp":"What's the required input?","code":"","choices":[{"id":"a","text":"Aspect-ratio reservation via width/height (or fill in a sized container)"},{"id":"b","text":"By converting to WebP"},{"id":"c","text":"By disabling lazy loading"},{"id":"d","text":"It can't"}],"correctAnswerIds":["a"],"explanation":"With intrinsic dimensions known before load, the browser reserves the box — the shift never happens regardless of network speed.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: next/image — optimization and priority","url":"https://nextjs.org/docs/app/api-reference/components/image"}},"databaseId":"6ab19586b8dd2d82472cb3a0"},{"id":"nextjs-0ed1-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What's the cost of marking many images priority?","intro":"Bandwidth contention.","images":[],"followUp":"What's the right count?","code":"","choices":[{"id":"a","text":"They compete for bandwidth and delay the actual LCP — priority belongs to the single LCP image"},{"id":"b","text":"None — preloads are free"},{"id":"c","text":"Only on mobile"},{"id":"d","text":"It disables lazy loading app-wide"}],"correctAnswerIds":["a"],"explanation":"Preload bandwidth is finite: five preloaded images starve the hero. One priority per page (the LCP element).","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: next/image — optimization and priority","url":"https://nextjs.org/docs/app/api-reference/components/image"}},"databaseId":"6ab19586b8dd2d82472cb3a1"},{"id":"nextjs-0ed1-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: next/image lazy-loads by default.","intro":"Default behavior.","images":[],"followUp":"Which images should opt out?","code":"","choices":[{"id":"a","text":"True — everything below the fold lazy-loads; only the LCP image needs priority"},{"id":"b","text":"False — everything loads eagerly"},{"id":"c","text":"True, but only on iOS"},{"id":"d","text":"False — lazy loading was removed"}],"correctAnswerIds":["a"],"explanation":"Default lazy is the correct baseline for CWV; opt-out is the exception reserved for the above-fold LCP image.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: next/image — optimization and priority","url":"https://nextjs.org/docs/app/api-reference/components/image"}},"databaseId":"6ab19586b8dd2d82472cb3a2"}]},{"id":"6aa2b1d3a7147974707d0ed2","question":"How do you prevent font loading from causing CLS in Next.js?","shortAnswer":"Use next/font or carefully controlled font loading, select metric-compatible fallbacks, preload only critical fonts, limit weights, and measure shifts caused when the final font replaces fallback text.","longAnswer":"Font-caused CLS happens when the fallback font's metrics differ from the web font's, so text reflows on swap — the fix is metric-matched fallbacks, which next/font does automatically: it generates a size-adjusted local fallback (@font-face with ascent-override/size-adjust computed from the actual font) so the placeholder occupies the same space the real font will. Supporting practices: font-display: swap with the metric-adjusted fallback (never block rendering on the font); preload only the fonts actually needed for initial paint (next/font handles subsetting + preloading); avoid adding font families mid-design; and keep the count/weights small (each family/weight is another swap risk). Verifying: Lighthouse/CLS field data after deploy, and the rendered @font-face should show the adjusted overrides.","images":[],"codeSnippets":[{"title":"next/font setup that prevents CLS","language":"tsx","code":"// app/layout.tsx\nimport { Inter, Roboto_Mono } from 'next/font/google';\n\n// next/font: subsets at build, self-hosts, preloads, and generates a\n// size-adjusted fallback so the swap causes zero reflow.\nconst inter = Inter({\n subsets: ['latin'],\n display: 'swap',\n variable: '--font-inter',\n});\nconst mono = Roboto_Mono({ subsets: ['latin'], variable: '--font-mono' });\n\nexport default function RootLayout({ children }) {\n return (\n \n {children}\n \n );\n}\n// Verify: DevTools → document.fonts → the fallback @font-face carries\n// ascent-override/size-adjust values derived from Inter's metrics."}],"references":[{"title":"Next.js Docs: next/font — automatic self-hosting and fallback adjustment","url":"https://nextjs.org/docs/app/building-your-application/optimizing/fonts"},{"title":"web.dev: Prevent layout shifting and flashes of invisible text (FOIT/FOUT)","url":"https://web.dev/articles/font-best-practices"}],"tips":["next/font's magic is size-adjust on the fallback — if you hand-roll @font-face, you must compute those overrides yourself or accept the reflow.","Self-host via next/font (default): no third-party font CSS request, subsetting at build, and preloading wired to the actual usage — all three reduce swap risk."],"challenges":[],"mcqs":[{"id":"nextjs-0ed2-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What causes the layout shift when a web font loads?","intro":"Mechanism.","images":[],"followUp":"What property fixes it?","code":"","choices":[{"id":"a","text":"Fallback font metrics differ from the web font — size-adjust/ascent-override fallbacks fix it"},{"id":"b","text":"The font file is too large"},{"id":"c","text":"Fonts disable CSS"},{"id":"d","text":"Missing font license"}],"correctAnswerIds":["a"],"explanation":"Shift = reflow when glyph metrics change. Metric-matched fallbacks hold the space, so the swap is visually invisible.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: next/font — automatic self-hosting and fallback adjustment","url":"https://nextjs.org/docs/app/building-your-application/optimizing/fonts"}},"databaseId":"6ab19585b8dd2d82472cb39c"},{"id":"nextjs-0ed2-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What does next/font generate automatically to prevent CLS?","intro":"Tooling.","images":[],"followUp":"What does it base the values on?","code":"","choices":[{"id":"a","text":"A size-adjusted @font-face fallback computed from the web font's metrics"},{"id":"b","text":"A server-side font renderer"},{"id":"c","text":"A PNG snapshot"},{"id":"d","text":"Nothing — it only subsets"}],"correctAnswerIds":["a"],"explanation":"The build measures the font and emits overrides so the fallback occupies identical space — hand-tuning becomes unnecessary.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: next/font — automatic self-hosting and fallback adjustment","url":"https://nextjs.org/docs/app/building-your-application/optimizing/fonts"}},"databaseId":"6ab19585b8dd2d82472cb39d"},{"id":"nextjs-0ed2-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why is font-display: swap the right choice with adjusted fallbacks?","intro":"Display strategy.","images":[],"followUp":"What would 'block' cause instead?","code":"","choices":[{"id":"a","text":"Text renders immediately in the (space-correct) fallback — no invisible-text period; block hides text while waiting"},{"id":"b","text":"Swap disables caching"},{"id":"c","text":"Block is faster on slow networks"},{"id":"d","text":"Swap causes CLS"}],"correctAnswerIds":["a"],"explanation":"With metrics matched, swap shows correct-layout text instantly; block trades visible content for a (now pointless) guarantee.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: next/font — automatic self-hosting and fallback adjustment","url":"https://nextjs.org/docs/app/building-your-application/optimizing/fonts"}},"databaseId":"6ab19585b8dd2d82472cb39e"}]},{"id":"6aa2b1d3a7147974707d0ed3","question":"How do you design SEO for dynamic routes?","shortAnswer":"Generate metadata from the route's canonical resource, return not-found metadata for missing content, define canonical URLs, expose crawlable HTML where appropriate, and avoid indexing private or duplicate variants.","longAnswer":"Dynamic-route SEO is metadata generation plus canonical discipline. generateMetadata (per route, receiving params/searchParams and fetching the page's own data) produces title, description, openGraph, twitter, and canonical per instance; robots directives (noindex for filtered/duplicated views) and structured data (JSON-LD Product/Article/FAQ) travel with the page's RSC payload. Canonical discipline covers the hidden traps: trailing slashes and query-order variants, paginated series (rel prev/next has been retired — canonical stays self and pagination is crawlable through links), optional catch-all routes emitting duplicate paths for the same content, and hreflang alternates for localized params. The test: fetch a rendered dynamic page as a bot (curl + rich results test) and verify the head output — not just what you see in the browser.","images":[],"codeSnippets":[{"title":"generateMetadata with memoized fetch + canonical","language":"tsx","code":"$51"}],"references":[{"title":"Next.js Docs: generateMetadata — dynamic metadata","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata"},{"title":"Google Search Central: consolidating duplicate URLs — canonicalization","url":"https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls"}],"tips":["Put the SAME fetch call (same tags/revalidate) in generateMetadata and the page — request memoization makes the second call free and guarantees the metadata matches the content.","For filterable listings, canonical the clean base URL and noindex the parameterized variants — otherwise faceted search floods the index with thin duplicates."],"challenges":[],"mcqs":[{"id":"nextjs-0ed3-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"How does a dynamic product page get per-product title and OG tags?","intro":"Mechanism.","images":[],"followUp":"What does generateMetadata receive?","code":"","choices":[{"id":"a","text":"generateMetadata(params) fetches the product and returns its metadata object"},{"id":"b","text":"A shared static template"},{"id":"c","text":"Client-side document.title mutation"},{"id":"d","text":"Middleware injects tags"}],"correctAnswerIds":["a"],"explanation":"generateMetadata runs per request/prerender with route params, so each dynamic instance ships its own head — crawled correctly.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: generateMetadata — dynamic metadata","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata"}},"databaseId":"6ab19584b8dd2d82472cb398"},{"id":"nextjs-0ed3-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A listing page supports ?sort=price&filter=red with identical content. SEO handling?","intro":"Duplicate control.","images":[],"followUp":"What does the canonical point to?","code":"","choices":[{"id":"a","text":"Canonical to the clean URL and noindex the parameterized variants"},{"id":"b","text":"Index every variant"},{"id":"c","text":"Redirect all variants to 404"},{"id":"d","text":"Nothing — URLs don't matter"}],"correctAnswerIds":["a"],"explanation":"Faceted variants are the classic thin-duplicate generator: consolidate equity to the canonical and keep parameterized URLs out of the index.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: generateMetadata — dynamic metadata","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata"}},"databaseId":"6ab19585b8dd2d82472cb399"},{"id":"nextjs-0ed3-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: generateMetadata and the page fetching the same data costs two requests.","intro":"Memoization interplay.","images":[],"followUp":"What makes the second call free?","code":"","choices":[{"id":"a","text":"False — request memoization deduplicates the identical fetch within the render pass"},{"id":"b","text":"True — always two"},{"id":"c","text":"True, unless PPR"},{"id":"d","text":"False — metadata is cached client-side"}],"correctAnswerIds":["a"],"explanation":"Same URL + same options in one render = one network call. This is why metadata and page can share the exact fetch helper.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: generateMetadata — dynamic metadata","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata"}},"databaseId":"6ab19585b8dd2d82472cb39a"},{"id":"nextjs-0ed3-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"An optional catch-all (/[[...slug]]) renders the same article at /a/b and /a. Crawl effect and fix?","intro":"Route-shape scenario.","images":[],"followUp":"Where is the fix expressed?","code":"","choices":[{"id":"a","text":"Duplicate URLs dilute signals — pick one canonical path per article (via redirect or canonical tag)"},{"id":"b","text":"Catch-alls are invisible to crawlers"},{"id":"c","text":"Fix by removing generateMetadata"},{"id":"d","text":"Nothing — React dedupes URLs"}],"correctAnswerIds":["a"],"explanation":"Crawlers see both URLs. Choose the canonical shape (usually the shorter) and redirect/canonical the rest in the data layer or generateMetadata.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: generateMetadata — dynamic metadata","url":"https://nextjs.org/docs/app/api-reference/functions/generate-metadata"}},"databaseId":"6ab19585b8dd2d82472cb39b"}]},{"id":"6aa2b1d3a7147974707d0ed4","question":"How do you generate sitemap and robots behavior for an App Router site?","shortAnswer":"Use the framework metadata file conventions to generate only canonical public URLs, exclude private or parameter combinations that should not be indexed, and keep generated output consistent with authorization and content availability.","longAnswer":"The App Router replaces static files with conventions that run as code: app/sitemap.ts exports a default function returning MetadataRoute.Sitemap entries (url, lastModified, changeFrequency, priority, alternates), which can be fully dynamic — generated from the database/CMS so newly published pages enter the sitemap immediately, with cache/revalidate applied to the underlying fetch. app/robots.ts exports a MetadataRoute.Robots (rules: user-agent/allow/disallow, plus sitemap URL) covering the same policies robots.txt would. Both are served at the conventional URLs, both support per-route caching, and both should be deployed with the same care as any dynamic route: correct canonical URLs (including www/trailing-slash decisions), environment-based hosts, and validation of the output before going live.","images":[],"codeSnippets":[{"title":"Dynamic sitemap + robots from env","language":"ts","code":"// app/sitemap.ts\nimport type { MetadataRoute } from 'next';\n\nexport const revalidate = 3600; // cheap regeneration\n\nexport default async function sitemap(): Promise {\n const base = process.env.NEXT_PUBLIC_SITE_URL; // canonical host from env\n const posts = await getPublishedPosts(); // DB/CMS — new content appears automatically\n return [\n { url: base, changeFrequency: 'daily', priority: 1 },\n ...posts.map((p) => ({\n url: `${base}/blog/${p.slug}`,\n lastModified: p.updatedAt,\n changeFrequency: 'weekly' as const,\n priority: 0.7,\n })),\n ];\n}\n\n// app/robots.ts\nimport type { MetadataRoute } from 'next';\nexport default function robots(): MetadataRoute.Robots {\n const base = process.env.NEXT_PUBLIC_SITE_URL;\n return {\n rules: process.env.VERCEL_ENV === 'production'\n ? { userAgent: '*', allow: '/' }\n : { userAgent: '*', disallow: '/' }, // staging: crawl nothing\n sitemap: `${base}/sitemap.xml`,\n };\n}"}],"references":[{"title":"Next.js Docs: sitemap.js — generating sitemaps","url":"https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap"},{"title":"Next.js Docs: robots.js — generating robots.txt","url":"https://nextjs.org/docs/app/api-reference/file-conventions/metadata/robots"}],"tips":["Drive the sitemap from your canonical source (DB/CMS) rather than file-listing routes — marketing pages built from content tables otherwise never appear.","Set robots to disallow staging AND generate the sitemap with the production host from env — the classic silent SEO bug is a staging sitemap shipping to prod."],"challenges":[],"mcqs":[{"id":"nextjs-0ed4-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What does app/sitemap.ts return?","intro":"Convention.","images":[],"followUp":"Where is it served?","code":"","choices":[{"id":"a","text":"A MetadataRoute.Sitemap (url/lastModified/priority list) served at /sitemap.xml"},{"id":"b","text":"A JSON manifest consumed at build"},{"id":"c","text":"HTML pages"},{"id":"d","text":"A robots object"}],"correctAnswerIds":["a"],"explanation":"The file convention compiles to the standard URL crawlers request; it's code, so it can query your data source.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: sitemap.js — generating sitemaps","url":"https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap"}},"databaseId":"6ab19584b8dd2d82472cb395"},{"id":"nextjs-0ed4-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why make the sitemap dynamic instead of committing a static file?","intro":"Freshness.","images":[],"followUp":"What mechanism keeps it cheap?","code":"","choices":[{"id":"a","text":"New/deleted pages must enter/leave the sitemap immediately; caching (revalidate) keeps the dynamic generation cheap"},{"id":"b","text":"Static sitemaps are invalid XML"},{"id":"c","text":"Dynamic sitemaps rank higher"},{"id":"d","text":"Static files can't list URLs"}],"correctAnswerIds":["a"],"explanation":"Sitemap staleness means crawlers miss new content; the fetch-level cache makes freshness essentially free.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: sitemap.js — generating sitemaps","url":"https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap"}},"databaseId":"6ab19584b8dd2d82472cb396"},{"id":"nextjs-0ed4-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"In robots.ts, which entry pairs with Disallow to complete a correct policy?","intro":"Robots mechanics.","images":[],"followUp":"What else does the file usually reference?","code":"","choices":[{"id":"a","text":"User-Agent rules plus the Sitemap URL — crawlers discover the sitemap from robots.txt"},{"id":"b","text":"Meta tags"},{"id":"c","text":"Alt-text rules"},{"id":"d","text":"Canonical links"}],"correctAnswerIds":["a"],"explanation":"robots.txt is policy + discovery: allow/disallow per agent, and the Sitemap: line pointing at /sitemap.xml.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: sitemap.js — generating sitemaps","url":"https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap"}},"databaseId":"6ab19584b8dd2d82472cb397"}]},{"id":"6aa2b1d3a7147974707d0ed5","question":"How do partial prerendering and streaming change the performance model?","shortAnswer":"They allow stable shell output to be prepared or cached while dynamic holes resolve later, but the design must still account for cache boundaries, fallback quality, hydration cost, and the critical path to meaningful content.","longAnswer":"Partial prerendering (PPR) and streaming change the performance model from binary (static OR dynamic) to composed: a static shell is prepared/cached ahead of time, while dynamic holes inside Suspense boundaries resolve per request and stream in. The user-visible result: instant shell (static economics) plus per-request personalization (dynamic correctness). The performance accounting still matters: the shell's quality determines perceived speed (a good skeleton beats a blank frame), each dynamic hole still costs its data fetch (streamed ≠ free), hydration cost remains for interactive islands, and cache boundaries decide which parts benefit from the static tier. The design question shifts from 'which mode' to 'which parts of the page earn which mode'.","images":[],"codeSnippets":[{"title":"PPR-shaped page: static shell, dynamic holes","language":"tsx","code":"// app/product/[id]/page.tsx (PPR enabled)\nimport { Suspense } from 'react';\n\n// STATIC SHELL — prerendered, CDN-served:\nexport async function generateStaticParams() {\n return (await getProductIds()).map((id) => ({ id }));\n}\n\nexport default function ProductPage() {\n return (\n <>\n {/* static: shared data in the shell */}\n }>\n {/* DYNAMIC hole: session-aware, streams */}\n \n }>\n {/* hole: slow shared query, streams */}\n \n \n );\n}\n// Cold request: shell instantly from cache; holes stream as data lands."}],"references":[{"title":"Next.js Docs: Partial prerendering (PPR) overview","url":"https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering"},{"title":"Next.js Docs: Streaming — progressive delivery model","url":"https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming"}],"tips":["With PPR, layout choice = money: every part you move into the static shell is CDN-served; every hole you open is per-request work. Draw the line deliberately.","Fallbacks become the real first paint under PPR — invest in skeleton quality the way you'd invest in a landing page."],"challenges":[],"mcqs":[{"id":"nextjs-0ed5-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What does partial prerendering combine?","intro":"Core model.","images":[],"followUp":"What serves the shell?","code":"","choices":[{"id":"a","text":"A statically prerendered shell with dynamic holes that stream per request inside Suspense"},{"id":"b","text":"SSR and client rendering"},{"id":"c","text":"Edge and Node runtimes"},{"id":"d","text":"Static and nothing else"}],"correctAnswerIds":["a"],"explanation":"PPR is the composition: cached shell instantaneously, dynamic segments streamed as their data resolves — no mode choice forced.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Partial prerendering (PPR) overview","url":"https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering"}},"databaseId":"6ab19582b8dd2d82472cb38e"},{"id":"nextjs-0ed5-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Under PPR, what determines perceived load speed?","intro":"Shell quality.","images":[],"followUp":"What should the shell contain?","code":"","choices":[{"id":"a","text":"The shell's quality — layout, skeletons, and static content arriving instantly"},{"id":"b","text":"The slowest dynamic hole"},{"id":"c","text":"The CDN region"},{"id":"d","text":"Bundle size only"}],"correctAnswerIds":["a"],"explanation":"The user's first paint IS the shell. A complete-feeling shell at 100ms beats a full page at 2s — that's the model's promise.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Partial prerendering (PPR) overview","url":"https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering"}},"databaseId":"6ab19583b8dd2d82472cb38f"},{"id":"nextjs-0ed5-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: streaming a dynamic hole makes its data fetch free.","intro":"Cost accounting.","images":[],"followUp":"What still bounds the hole's completion?","code":"","choices":[{"id":"a","text":"False — the fetch still runs per request; streaming hides the wait, it doesn't remove the work"},{"id":"b","text":"True — streamed data is cached"},{"id":"c","text":"True on Edge"},{"id":"d","text":"False — holes can't fetch"}],"correctAnswerIds":["a"],"explanation":"The Data Cache still matters: a cached fetch makes the hole fast; an uncached one streams late. Latency engineering continues inside holes.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Partial prerendering (PPR) overview","url":"https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering"}},"databaseId":"6ab19583b8dd2d82472cb390"},{"id":"nextjs-0ed5-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Product page: static info for all users, 'your price' per user, reviews (slow query). PPR structure?","intro":"Design scenario.","images":[],"followUp":"What does a cold request feel like?","code":"","choices":[{"id":"a","text":"Shell = product info (static); holes = your-price + reviews (streamed); instant shell, personalized/streamed completion"},{"id":"b","text":"Everything dynamic"},{"id":"c","text":"Everything static"},{"id":"d","text":"Static price, dynamic product"}],"correctAnswerIds":["a"],"explanation":"Shared data earns the static tier; per-user and slow-but-shared streams become holes. The user sees the page immediately and watches the rest fill in.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Partial prerendering (PPR) overview","url":"https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering"}},"databaseId":"6ab19583b8dd2d82472cb391"}]},{"id":"6aa2b1d3a7147974707d0ed6","question":"How do you investigate hydration mismatches?","shortAnswer":"Compare server and client output, find nondeterministic values such as time or random IDs, isolate browser-only APIs, check locale and data differences, and avoid suppressing warnings unless the mismatch is intentional and safe.","longAnswer":"A hydration mismatch means the server's HTML and the client's first render disagreed — React discards and re-renders the region, costing performance and warning loudly. The causes are nondeterminism: time/locale-dependent formatting (new Date(), toLocaleDateString differing by server locale), Math.random() or crypto IDs during render, browser-only state read during render (localStorage, window dimensions), locale/timezone differences between server and browser, and browser extensions mutating the DOM. The fixes: render deterministic content on both sides (format on the server and ship strings; compute client-only values in useEffect after mount), gate browser-only UI behind mounted state, and use suppressHydrationWarning only for known-safe intentional differences (like a timestamp), never as a general silencer.","images":[],"codeSnippets":[{"title":"Deterministic render + post-mount personalization","language":"tsx","code":"'use client';\nimport { useEffect, useState } from 'react';\n\n// ❌ Mismatch: server (UTC) and client (local) compute different strings.\n//

{new Date().toLocaleTimeString()}

\n\n// ✅ Deterministic server output, personalized after mount:\nexport function Clock() {\n const [time, setTime] = useState(null);\n useEffect(() => {\n const tick = () => setTime(new Date().toLocaleTimeString());\n tick();\n const id = setInterval(tick, 1000);\n return () => clearInterval(id);\n }, []);\n return {time ?? '--:--:--'};\n // Server + first client render both emit '--:--:--' → no mismatch.\n // suppressHydrationWarning covers the (intentional) per-second updates.\n}"}],"references":[{"title":"Next.js Docs: Hydration errors — causes and fixes","url":"https://nextjs.org/docs/messages/react-hydration-error"},{"title":"React Docs: hydrateRoot — why mismatches happen","url":"https://react.dev/reference/react-dom/hydrateRoot"}],"tips":["The reliable recipe for dates: format them on the server into strings (deterministic), or render a placeholder and fill the locale-correct string in useEffect.","Debug with the warning's diff — React 18+ shows exactly which attribute/text diverged. Fix the source of nondeterminism, not the symptom."],"challenges":[],"mcqs":[{"id":"nextjs-0ed6-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which pattern causes a hydration mismatch?","intro":"Cause identification.","images":[],"followUp":"Which does NOT?","code":"","choices":[{"id":"a","text":"new Date().toLocaleTimeString() in render — server and client clocks/locales differ"},{"id":"b","text":"Static text from props"},{"id":"c","text":"Server-fetched data"},{"id":"d","text":"CSS classes"}],"correctAnswerIds":["a"],"explanation":"Anything computed from clock/locale/randomness can diverge between server and client. Deterministic props and server-fetched data don't.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Hydration errors — causes and fixes","url":"https://nextjs.org/docs/messages/react-hydration-error"}},"databaseId":"6ab19582b8dd2d82472cb38a"},{"id":"nextjs-0ed6-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What's the effect of a hydration mismatch on the user?","intro":"Runtime consequence.","images":[],"followUp":"What does React 18 do to the mismatched region?","code":"","choices":[{"id":"a","text":"A flicker/flash as React discards and re-renders the diverged region"},{"id":"b","text":"Nothing — it self-corrects silently"},{"id":"c","text":"A full page reload"},{"id":"d","text":"A 500 error"}],"correctAnswerIds":["a"],"explanation":"React falls back to client rendering for the mismatched subtree: visible re-render plus wasted work — the perf cost is real, not just console noise.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Hydration errors — causes and fixes","url":"https://nextjs.org/docs/messages/react-hydration-error"}},"databaseId":"6ab19582b8dd2d82472cb38b"},{"id":"nextjs-0ed6-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: suppressHydrationWarning is the standard fix for mismatches.","intro":"Suppression discipline.","images":[],"followUp":"When IS it appropriate?","code":"","choices":[{"id":"a","text":"False — it's for known-safe single-element differences (timestamps); fix the actual nondeterminism otherwise"},{"id":"b","text":"True — apply it liberally"},{"id":"c","text":"True, in production builds"},{"id":"d","text":"False — it's removed in React 18"}],"correctAnswerIds":["a"],"explanation":"Suppression hides real bugs (browser-only state in render, wrong data). Legitimate use is narrow: intentional, harmless divergence like a clock.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Hydration errors — causes and fixes","url":"https://nextjs.org/docs/messages/react-hydration-error"}},"databaseId":"6ab19582b8dd2d82472cb38c"},{"id":"nextjs-0ed6-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A component renders a 'good morning/afternoon' greeting. Mismatch on some users. Fix?","intro":"Locale/time scenario.","images":[],"followUp":"What renders during SSR?","code":"","choices":[{"id":"a","text":"Render a neutral placeholder on the server; compute the greeting in useEffect with the user's local time"},{"id":"b","text":"Force UTC on the server"},{"id":"c","text":"suppressHydrationWarning"},{"id":"d","text":"Remove the greeting"}],"correctAnswerIds":["a"],"explanation":"The user's timezone only exists in the browser. Server renders neutral (deterministic), client personalizes after mount — no mismatch, correct greeting.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Hydration errors — causes and fixes","url":"https://nextjs.org/docs/messages/react-hydration-error"}},"databaseId":"6ab19582b8dd2d82472cb38d"}]},{"id":"6aa2b1d3a7147974707d0ed7","question":"What causes hydration cost to remain high even with Server Components?","shortAnswer":"Interactive Client Components, large client dependencies, excessive provider scope, and broad use client boundaries still ship and hydrate JavaScript, so minimize their tree and data requirements.","longAnswer":"Server Components don't hydrate — but a Next.js app's hydration cost is whatever its Client Components, their dependencies, and their tree positions cost. The remaining causes of high hydration: oversized 'use client' boundaries (whole pages/layouts made client), heavy client dependencies (chart editors, date pickers, animation suites), provider pyramids near the root (forcing the whole subtree client), and state that must hydrate before interaction (controlled inputs over large lists). The fixes are the boundary disciplines: leaf islands, children slots, narrower dependencies (or lighter libraries), and deferring non-critical hydration (dynamic imports, lazy islands below the fold). Measure with hydration timings per route — 'time to interactive' is the metric the work moves.","images":[],"codeSnippets":[{"title":"Lazy island for below-fold interactivity","language":"tsx","code":"// components/lazy-editor.tsx ('use client') — hydrates when visible\n'use client';\nimport dynamic from 'next/dynamic';\nimport { useInView } from 'react-intersection-observer';\n\nconst Editor = dynamic(() => import('./editor-impl')); // heavy deps load on demand\n\nexport function LazyEditor(props) {\n const { ref, inView } = useInView({ rootMargin: '200px' });\n return (\n

\n {inView ? : }\n

\n );\n}\n// Above-the-fold content hydrates immediately; the editor's 180KB of\n// dependencies only parse/execute when the user actually scrolls to it."}],"references":[{"title":"Next.js Docs: Client Components — reducing bundle size and hydration","url":"https://nextjs.org/docs/app/building-your-application/rendering/client-components#moving-client-components-to-the-leaves"},{"title":"web.dev: Optimize INP and hydration costs","url":"https://web.dev/articles/inp"}],"tips":["Profile hydration like a render: React DevTools timing + the performance panel show which client subtree owns the cost — usually one provider or one heavy dependency.","Below-the-fold interactive widgets can hydrate late (dynamic import on intersection) — users don't miss what they can't see yet."],"challenges":[],"mcqs":[{"id":"nextjs-0ed7-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why can hydration cost stay high even in an RSC app?","intro":"Residual cost model.","images":[],"followUp":"Which component class hydrates?","code":"","choices":[{"id":"a","text":"Client Components, their dependencies, and their tree size still ship and hydrate"},{"id":"b","text":"Server Components hydrate slowly"},{"id":"c","text":"RSC apps don't hydrate at all"},{"id":"d","text":"Only the root hydrates"}],"correctAnswerIds":["a"],"explanation":"RSC removes server-component hydration, but every 'use client' island (and its imports) still parses, executes, and attaches.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Client Components — reducing bundle size and hydration","url":"https://nextjs.org/docs/app/building-your-application/rendering/client-components#moving-client-components-to-the-leaves"}},"databaseId":"6ab19581b8dd2d82472cb386"},{"id":"nextjs-0ed7-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A root-level Providers client component wraps the whole app. Effect?","intro":"Provider placement.","images":[],"followUp":"What's the mitigation?","code":"","choices":[{"id":"a","text":"The entire subtree becomes client and hydrates — narrow provider scope to the consumers that need it"},{"id":"b","text":"None — providers are cheap"},{"id":"c","text":"Only the provider hydrates"},{"id":"d","text":"It disables streaming"}],"correctAnswerIds":["a"],"explanation":"'use client' on a root provider is a whole-app boundary in disguise. Scope context/providers to their actual consumers.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Client Components — reducing bundle size and hydration","url":"https://nextjs.org/docs/app/building-your-application/rendering/client-components#moving-client-components-to-the-leaves"}},"databaseId":"6ab19581b8dd2d82472cb387"},{"id":"nextjs-0ed7-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: hydration cost depends only on bundle size.","intro":"Cost structure.","images":[],"followUp":"What else scales it?","code":"","choices":[{"id":"a","text":"False — the number and depth of hydrated components, and their render work, matter as much"},{"id":"b","text":"True — bytes decide"},{"id":"c","text":"True, on slow networks only"},{"id":"d","text":"False — hydration is O(1)"}],"correctAnswerIds":["a"],"explanation":"Hydration re-executes the client tree: a 50KB bundle rendering 5,000 components costs more main-thread time than 100KB rendering 20.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Client Components — reducing bundle size and hydration","url":"https://nextjs.org/docs/app/building-your-application/rendering/client-components#moving-client-components-to-the-leaves"}},"databaseId":"6ab19581b8dd2d82472cb388"},{"id":"nextjs-0ed7-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A heavy editor widget sits below the fold. Hydration optimization?","intro":"Deferral scenario.","images":[],"followUp":"What triggers the import?","code":"","choices":[{"id":"a","text":"Lazy-hydrate it — dynamic import when it approaches the viewport (IntersectionObserver)"},{"id":"b","text":"Hydrate it eagerly with everything else"},{"id":"c","text":"Move it to the server"},{"id":"d","text":"Remove it from the page"}],"correctAnswerIds":["a"],"explanation":"Users interact top-down: deferring below-fold hydration moves that cost out of the critical 'page usable' window entirely.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Client Components — reducing bundle size and hydration","url":"https://nextjs.org/docs/app/building-your-application/rendering/client-components#moving-client-components-to-the-leaves"}},"databaseId":"6ab19581b8dd2d82472cb389"}]},{"id":"6aa2b1d3a7147974707d0ed8","question":"How do you prevent duplicate data fetching across server and client boundaries?","shortAnswer":"Fetch on the server when possible, pass the resolved serializable result to the client, share cached request functions for server work, and avoid a Client Component immediately refetching data already rendered into the page.","longAnswer":"Duplicate fetching appears when client components re-request data the server already resolved and embedded in the RSC payload — doubling latency, load, and the risk of inconsistency between server-rendered and client-fetched versions. The prevention is architectural: fetch on the server, pass the resolved result down as serializable props; reserve client fetching for data that genuinely changes after load (polling, post-interaction refresh). Within server code, React's request memoization deduplicates identical fetches in one render pass; the Data Cache extends that across requests. When a client island must have fresher data, it should fetch a DIFFERENT, narrower resource (an endpoint), not re-fetch the page's initial dataset.","images":[],"codeSnippets":[{"title":"Server-owned initial data, island-owned updates","language":"tsx","code":"// app/game/[id]/page.tsx — server: initial state rides the payload\nexport default async function GamePage({ params }: { params: { id: string } }) {\n const game = await getGame(params.id); // cached fetch\n return (\n <>\n {/* island gets initial via props */}\n {/* server-rendered, no client fetch */}\n \n );\n}\n\n// components/scoreboard.tsx ('use client') — updates via a NARROW endpoint\n'use client';\nexport function Scoreboard({ initial }: { initial: Score }) {\n const [score, setScore] = useState(initial);\n useEffect(() => {\n const es = new EventSource(`/api/games/${gameId}/score-stream`); // updates only\n es.onmessage = (e) => setScore(JSON.parse(e.data));\n return () => es.close();\n }, []);\n return

{score.home} – {score.away}

;\n}"}],"references":[{"title":"Next.js Docs: Fetching data — server-first patterns","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching"},{"title":"Next.js Docs: Request memoization","url":"https://nextjs.org/docs/app/building-your-application/caching#request-memoization"}],"tips":["The smell: a client component's useEffect fetching what its server parent already rendered. Pass it down; fetch only what the server couldn't know at render time.","Request memoization (same render pass) + Data Cache (across requests) + props-down (across the boundary) — three dedupe layers; use them in that order."],"challenges":[],"mcqs":[{"id":"nextjs-0ed8-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A page server-renders orders; a client child useEffects the same endpoint. Cost?","intro":"Duplication cost.","images":[],"followUp":"What's the fix?","code":"","choices":[{"id":"a","text":"Double latency/load and possible mismatch between server and client versions — pass the data as props instead"},{"id":"b","text":"None — caching dedupes automatically"},{"id":"c","text":"Only hydration cost"},{"id":"d","text":"A build error"}],"correctAnswerIds":["a"],"explanation":"The client fetch duplicates work the RSC payload already paid for — and the two copies can disagree (rendered vs refetched).","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Fetching data — server-first patterns","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching"}},"databaseId":"6ab19580b8dd2d82472cb382"},{"id":"nextjs-0ed8-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Two server components fetch the same URL in one render. Network calls?","intro":"Request memoization.","images":[],"followUp":"Which mechanism provides this?","code":"","choices":[{"id":"a","text":"One — request memoization deduplicates identical fetches within a render pass"},{"id":"b","text":"Two — always"},{"id":"c","text":"Zero — fetches are async-cached forever"},{"id":"d","text":"One, only in dev"}],"correctAnswerIds":["a"],"explanation":"React dedupes identical fetches per render: pages, layouts, and generateMetadata can share data freely without coordination.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Fetching data — server-first patterns","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching"}},"databaseId":"6ab19580b8dd2d82472cb383"},{"id":"nextjs-0ed8-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: client islands should refetch the page's initial dataset for freshness.","intro":"Freshness design.","images":[],"followUp":"What should the island fetch instead?","code":"","choices":[{"id":"a","text":"False — it should fetch a narrower resource (endpoint) covering only the data that actually changes"},{"id":"b","text":"True — refetch everything for consistency"},{"id":"c","text":"True, if using SWR"},{"id":"d","text":"False — islands can't fetch"}],"correctAnswerIds":["a"],"explanation":"Refetching the initial dataset duplicates the server's work; a narrow endpoint (the changed slice) keeps freshness cheap.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Fetching data — server-first patterns","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching"}},"databaseId":"6ab19581b8dd2d82472cb384"},{"id":"nextjs-0ed8-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A live-score widget needs updates the server render can't provide. Design?","intro":"Post-load data scenario.","images":[],"followUp":"What does the initial render use?","code":"","choices":[{"id":"a","text":"Server-render the initial scores; the island polls/SSEs a scores endpoint for updates only"},{"id":"b","text":"Client fetches everything on mount"},{"id":"c","text":"Server pushes HTML patches"},{"id":"d","text":"Meta refresh"}],"correctAnswerIds":["a"],"explanation":"Initial data rides the RSC payload (fast, consistent); updates flow through a dedicated endpoint. No duplicate fetch, live results.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Fetching data — server-first patterns","url":"https://nextjs.org/docs/app/building-your-application/data-fetching/fetching"}},"databaseId":"6ab19581b8dd2d82472cb385"}]},{"id":"6aa2b1d3a7147974707d0ed9","question":"How do you test rendering and caching behavior in Next.js?","shortAnswer":"Test route output under fresh, cached, revalidated, authenticated, unauthorized, error, and not-found conditions, and verify cache invalidation after mutations instead of testing only component snapshots.","longAnswer":"Testing Next.js rendering/caching means testing behaviors, not snapshots: route output under fresh vs cached conditions; revalidation (does revalidateTag actually refresh?); auth states (authenticated, unauthorized, anonymous — including the cross-user leakage test); error and not-found paths; and invalidation flows after mutations. Unit tests cover components and data functions; integration tests hit a production build (next build && next start) where caches exist; E2E tests walk user journeys across navigation. The cache tests are the distinctive discipline: seed, assert, mutate, invalidate, assert-again — because caching bugs only exist where caching exists, and dev-mode testing cannot see them.","images":[],"codeSnippets":[{"title":"An invalidation test against a production build","language":"ts","code":"// e2e/caching.spec.ts — Playwright against `next build && next start`\nimport { test, expect } from '@playwright/test';\n\ntest('product page reflects webhook updates', async ({ request, page }) => {\n await page.goto('/products/42');\n await expect(page.getByTestId('price')).toHaveText('$10.00');\n\n // 1. The source changes\n await request.patch('/api/test/products/42', { data: { priceCents: 1200 } });\n // 2. The webhook fires (what production does)\n await request.post('/api/cms-webhook', { data: { type: 'product.updated', id: 42 } });\n\n // 3. Fresh load shows the new data (Full Route + Data Cache were invalidated)\n await page.goto('/products/42');\n await expect(page.getByTestId('price')).toHaveText('$12.00');\n\n // 4. Client navigation ALSO shows fresh data (Router Cache invalidated)\n await page.goto('/products');\n await page.click('text=Product 42');\n await expect(page.getByTestId('price')).toHaveText('$12.00');\n});"}],"references":[{"title":"Next.js Docs: Testing — setting up Vitest and Playwright","url":"https://nextjs.org/docs/app/building-your-application/testing"},{"title":"Playwright Docs: Testing web apps — auth and storage state","url":"https://playwright.dev/docs/auth"}],"tips":["E2E against a production build, not dev: cache behavior, streaming order, and route classification only exist after next build. Dev tests of cache logic are theater.","The highest-value test suite here is small: (1) fresh-load vs navigation staleness, (2) cross-user leak, (3) webhook invalidation. These three catch the bugs that hurt."],"challenges":[],"mcqs":[{"id":"nextjs-0ed9-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why must cache behavior tests run against a production build?","intro":"Fidelity.","images":[],"followUp":"What does dev-mode cache testing give you?","code":"","choices":[{"id":"a","text":"Caches are disabled in dev — only next build && next start exercises the real layers"},{"id":"b","text":"Dev caches more aggressively"},{"id":"c","text":"It doesn't matter — caches are identical"},{"id":"d","text":"Only unit tests matter"}],"correctAnswerIds":["a"],"explanation":"Testing cache invalidation where no cache exists passes vacuously. The build is where the Data/Route caches exist.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Testing — setting up Vitest and Playwright","url":"https://nextjs.org/docs/app/building-your-application/testing"}},"databaseId":"6ab1957fb8dd2d82472cb37e"},{"id":"nextjs-0ed9-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which assertion verifies revalidateTag works?","intro":"Invalidation test shape.","images":[],"followUp":"What's the sequence?","code":"","choices":[{"id":"a","text":"Fetch route → assert content; trigger mutation + revalidateTag; fetch again → assert fresh content"},{"id":"b","text":"Snapshot the component"},{"id":"c","text":"Check the build output"},{"id":"d","text":"Time the response"}],"correctAnswerIds":["a"],"explanation":"Seed → mutate → invalidate → assert-fresh: the four-step loop that proves the invalidation path end to end.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Testing — setting up Vitest and Playwright","url":"https://nextjs.org/docs/app/building-your-application/testing"}},"databaseId":"6ab19580b8dd2d82472cb37f"},{"id":"nextjs-0ed9-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: component snapshot tests are sufficient for a Next.js app.","intro":"Test pyramid reality.","images":[],"followUp":"What layer do snapshots miss entirely?","code":"","choices":[{"id":"a","text":"False — snapshots miss rendering modes, caching, auth states, and streaming; add integration/E2E"},{"id":"b","text":"True — they cover everything"},{"id":"c","text":"True, with TypeScript"},{"id":"d","text":"False — snapshots are deprecated"}],"correctAnswerIds":["a"],"explanation":"Snapshots see one component in isolation; the framework's value (and its bug surface) is the surrounding behavior.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Testing — setting up Vitest and Playwright","url":"https://nextjs.org/docs/app/building-your-application/testing"}},"databaseId":"6ab19580b8dd2d82472cb380"},{"id":"nextjs-0ed9-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"A test suite is green but users report stale data. What's missing?","intro":"Coverage gap scenario.","images":[],"followUp":"Which test would have caught it?","code":"","choices":[{"id":"a","text":"Cache-flow tests (mutate → invalidate → assert fresh) against a production build"},{"id":"b","text":"More snapshot tests"},{"id":"c","text":"A typecheck"},{"id":"d","text":"Lint rules"}],"correctAnswerIds":["a"],"explanation":"Green snapshots say nothing about invalidation. The mutate-invalidate-assert loop against the built app is the test that bites.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Testing — setting up Vitest and Playwright","url":"https://nextjs.org/docs/app/building-your-application/testing"}},"databaseId":"6ab19580b8dd2d82472cb381"}]},{"id":"6aa2b1d3a7147974707d0eda","question":"How should observability distinguish server rendering from client navigation?","shortAnswer":"Record route, render mode, cache status, data latency, runtime, hydration or client transition timing, and user outcome metrics so a slow server request is not confused with a slow client render.","longAnswer":"Observability for a Next.js app must separate two worlds that users experience as one: server rendering (request time, runtime, cache status, data-fetch latency, region) and client navigation (hydration timing, Router Cache hit/miss, interaction latency, Core Web Vitals as field data). The server side is structured tracing: one span per request, labeled with route, render mode, cache HIT/MISS/STALE per layer, and per-fetch durations. The client side is RUM: page-load and navigation timings, hydration completion, and vitals beacons. Correlating the two (request ID flowing from middleware to client beacon) is what lets you answer 'slow page' precisely: server render slow (which fetch?), or client slow (hydration? data? interaction?).","images":[],"codeSnippets":[{"title":"Server span + client beacon, joined by trace ID","language":"ts","code":"// instrumentation.ts — server spans (Next.js instrumentation hook)\nexport async function register() {\n const { trace } = await import('@opentelemetry/api');\n // Next.js + OTel auto-instrument requests; enrich with cache labels:\n // attributes: { 'next.route', 'render.mode', 'datacache.hit', 'fetch.duration' }\n}\n\n// components/vitals.tsx ('use client') — field RUM\nimport { onCLS, onINP, onLCP } from 'web-vitals';\nimport { usePathname } from 'next/navigation';\nexport function Vitals() {\n const pathname = usePathname();\n useEffect(() => {\n const report = (m: any) => navigator.sendBeacon('/api/vitals', JSON.stringify({\n ...m, pathname, traceId: document.documentElement.dataset.traceId, // joins server + client\n }));\n onCLS(report); onINP(report); onLCP(report);\n }, [pathname]);\n return null;\n}"}],"references":[{"title":"Next.js Docs: Observability — instrumentation and tracing","url":"https://nextjs.org/docs/app/building-your-application/optimizing/instrumentation"},{"title":"web.dev: Core Web Vitals — field measurement with web-vitals","url":"https://web.dev/articles/vitals"}],"tips":["Label every server span with route + render mode + cache status — the query 'is /dashboard slow because of data fetches or rendering?' should be one filter away.","Ship Core Web Vitals from real users (web-vitals beacon) — lab numbers from build machines never show the p75 user on a mid-range phone."],"challenges":[],"mcqs":[{"id":"nextjs-0eda-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why must server render and client navigation be measured separately?","intro":"Diagnosis precision.","images":[],"followUp":"What does conflation produce?","code":"","choices":[{"id":"a","text":"They have different causes and fixes — server span data vs hydration/interaction timings"},{"id":"b","text":"They can't be measured at all"},{"id":"c","text":"Only SEO requires it"},{"id":"d","text":"They're always identical"}],"correctAnswerIds":["a"],"explanation":"A slow dashboard could be a 2s query (server span) or 3s hydration (client trace). One blended number hides which lever to pull.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Observability — instrumentation and tracing","url":"https://nextjs.org/docs/app/building-your-application/optimizing/instrumentation"}},"databaseId":"6ab1957fb8dd2d82472cb37a"},{"id":"nextjs-0eda-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Which fields belong on a server-render span?","intro":"Span design.","images":[],"followUp":"What does cache status add?","code":"","choices":[{"id":"a","text":"Route, render mode, cache HIT/MISS per layer, per-fetch latencies, runtime, region"},{"id":"b","text":"Only total duration"},{"id":"c","text":"User's browser version"},{"id":"d","text":"CLS score"}],"correctAnswerIds":["a"],"explanation":"Cache status is the highest-value label: a latency regression on HIT vs MISS paths is a completely different investigation.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Observability — instrumentation and tracing","url":"https://nextjs.org/docs/app/building-your-application/optimizing/instrumentation"}},"databaseId":"6ab1957fb8dd2d82472cb37b"},{"id":"nextjs-0eda-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: Lab Lighthouse scores are sufficient production observability.","intro":"Lab vs field.","images":[],"followUp":"What does field data (RUM) capture that lab can't?","code":"","choices":[{"id":"a","text":"False — field RUM captures real devices/networks and post-load interactions; lab is synthetic"},{"id":"b","text":"True — lab covers production"},{"id":"c","text":"True, on Edge"},{"id":"d","text":"False — lab is more accurate"}],"correctAnswerIds":["a"],"explanation":"Your p75 user's phone on hotel Wi-Fi doesn't exist in the lab. Beacons (web-vitals, navigation timing) bring reality in.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Observability — instrumentation and tracing","url":"https://nextjs.org/docs/app/building-your-application/optimizing/instrumentation"}},"databaseId":"6ab1957fb8dd2d82472cb37c"},{"id":"nextjs-0eda-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Users say 'the dashboard is slow'. Your telemetry splits it. What two questions do you now answer?","intro":"Correlation scenario.","images":[],"followUp":"What joins the two datasets?","code":"","choices":[{"id":"a","text":"Is the server render slow (which fetch?) or the client (hydration/interaction)? — joined by request/trace ID"},{"id":"b","text":"Only 'how slow?'"},{"id":"c","text":"Which browser?"},{"id":"d","text":"Nothing — it's one number"}],"correctAnswerIds":["a"],"explanation":"The trace ID correlation turns a vague complaint into a specific fix: add an index, or split a client bundle — never guesswork.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Observability — instrumentation and tracing","url":"https://nextjs.org/docs/app/building-your-application/optimizing/instrumentation"}},"databaseId":"6ab1957fb8dd2d82472cb37d"}]},{"id":"6aa2b1d3a7147974707d0edb","question":"How do you plan deployment for a Next.js application with mixed runtimes?","shortAnswer":"Map each route, middleware function, image or font source, and data dependency to its runtime and cache behavior, then verify environment variables, regional execution, invalidation, logs, and fallback behavior in the target platform.","longAnswer":"Deploying an app with mixed runtimes (Node routes, Edge middleware, static routes, image/font optimization) is an inventory exercise: for every route and function, know its runtime, its data dependencies (and where they can be reached from), its cache behavior (what invalidates it, from where), and its region placement. Then verify the platform specifics: environment variables available at build vs runtime, whether Edge middleware supports the imported APIs, how revalidation webhooks reach the deployment (URL, auth), where logs from each runtime land, cold-start behavior per tier, and fallbacks when a dependency region is down. The deployment plan is a table — route × runtime × data × cache × region — reviewed like any other architecture artifact.","images":[],"codeSnippets":[{"title":"The deployment inventory table","language":"markdown","code":"| Route / Function | Runtime | Data deps | Cache / invalidation | Region |\n|-------------------------|---------|----------------------|-------------------------------|-----------|\n| / (marketing) | static | CMS (revalidate 1h) | revalidateTag('content') | global CDN|\n| /dashboard/* | node | Postgres (sessions) | force-dynamic, no-store | us-east |\n| middleware.ts | edge | none (cookie check) | n/a | all |\n| /api/quote/[sym] | edge | quotes API | no-store (live) | all |\n| /api/cms-webhook | node | CMS | calls revalidateTag/Path | us-east |\n| images | platform| remote allowlist | immutable, long TTL | global |\n\n// Checklist per row: env vars available there? secrets scoped? logs visible?\n// webhook reachable? region-fallback when data tier is down? P2 tested in staging."}],"references":[{"title":"Next.js Docs: Deploying — self-hosting and platform options","url":"https://nextjs.org/docs/app/building-your-application/deploying"},{"title":"Next.js Docs: Runtime selection — deployment implications","url":"https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes"}],"tips":["Webhook reachability is the forgotten dependency: revalidateTag flows die silently if the platform blocks external POSTs to your invalidation endpoint — test it in staging.","Per-runtime observability from day one: tag logs/metrics with runtime (node/edge) and region, or 'p99 latency' becomes an unanswerable question."],"challenges":[],"mcqs":[{"id":"nextjs-0edb-1","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"What's the first artifact of a mixed-runtime deployment plan?","intro":"Planning artifact.","images":[],"followUp":"What dimension is most often forgotten?","code":"","choices":[{"id":"a","text":"A route inventory: route × runtime × data deps × cache behavior × region"},{"id":"b","text":"A single global runtime choice"},{"id":"c","text":"A cost estimate only"},{"id":"d","text":"A Dockerfile"}],"correctAnswerIds":["a"],"explanation":"The table forces per-route decisions into the open — especially cache invalidation paths and regional data access, the commonly forgotten rows.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Deploying — self-hosting and platform options","url":"https://nextjs.org/docs/app/building-your-application/deploying"}},"databaseId":"6ab1957eb8dd2d82472cb376"},{"id":"nextjs-0edb-2","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Why must revalidation webhook URLs be verified on the target platform?","intro":"Invalidation reachability.","images":[],"followUp":"What breaks silently if unreachable?","code":"","choices":[{"id":"a","text":"On-demand invalidation drives content freshness — unreachable webhooks mean stale pages with no error"},{"id":"b","text":"Webhooks are cosmetic"},{"id":"c","text":"Builds fail instead"},{"id":"d","text":"Nothing — webhooks are optional"}],"correctAnswerIds":["a"],"explanation":"Staleness via missed webhooks is silent: no errors, just old pages. The staging test (publish → see fresh page) is the check.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Deploying — self-hosting and platform options","url":"https://nextjs.org/docs/app/building-your-application/deploying"}},"databaseId":"6ab1957eb8dd2d82472cb377"},{"id":"nextjs-0edb-3","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"True or false: environment variables behave identically across runtimes in production.","intro":"Platform nuance.","images":[],"followUp":"What's the common Edge env pitfall?","code":"","choices":[{"id":"a","text":"False — platforms scope env per runtime/edge region; NEXT_PUBLIC_ is build-time everywhere"},{"id":"b","text":"True — env is env"},{"id":"c","text":"False, but only for secrets"},{"id":"d","text":"True on all platforms"}],"correctAnswerIds":["a"],"explanation":"Edge functions may need env configured separately from Node functions on some platforms — and runtime (unprefixed) vars are unreadable client-side by design.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Deploying — self-hosting and platform options","url":"https://nextjs.org/docs/app/building-your-application/deploying"}},"databaseId":"6ab1957fb8dd2d82472cb378"},{"id":"nextjs-0edb-4","questionType":"single","technology":"Next.js and Rendering","level":"Advanced","topics":["Next.js and Rendering"],"question":"Prod incident: Edge middleware 500s in one region only. What does the deployment plan need to have anticipated?","intro":"Observability scenario.","images":[],"followUp":"What's the mitigation design?","code":"","choices":[{"id":"a","text":"Per-runtime, per-region logging/fallbacks — degradation strategy when one region's middleware fails"},{"id":"b","text":"Nothing — regions are identical"},{"id":"c","text":"A bigger server"},{"id":"d","text":"Client-side error tracking only"}],"correctAnswerIds":["a"],"explanation":"Edge fleets are regional: plan logs/metrics per region and a fail-open/fail-closed choice for what middleware guards.","metadata":{"estimatedTime":"2 min","author":"FrontCrate Editorial","lastUpdated":"2026-09-21","reference":{"label":"Next.js Docs: Deploying — self-hosting and platform options","url":"https://nextjs.org/docs/app/building-your-application/deploying"}},"databaseId":"6ab1957fb8dd2d82472cb379"}]}]}]}]}]]}]

Something went wrong loading this section.

Settings

Billing

Our products

We couldn't load checkout.

Welcome back, {session.user.name}