Episode 2 — React Frontend Architecture NextJS / 2.17 — Understanding Full Stack Frameworks

2.17 — Exercise Questions: Full Stack Frameworks

<< 2.17 Overview

A. Diagrams & mental models

Diagram: For one user click that mutates data, draw boxes for browser, CDN, server function, database, and external payment API. Label what a full stack framework typically owns vs what remains external.
Written: List six responsibilities that remain yours even when the framework provides server routes and SSR.
Sequence: Number the steps from “user submits form” to “UI reflects new state” in a single-system Next-style app vs a decoupled SPA + REST API. Where do types/validation naturally stay shared in each?

B. Comparison & research

Comparison matrix: Build a table with columns Rendering default mental model, Data loading / mutations, Deploy target, Best fit product shape. Fill rows for Next.js, Remix, Nuxt, SvelteKit, Astro (high level—verify current defaults in official docs).
Research (2026): Open current release notes for two frameworks you compared; note one breaking change and one stability or performance improvement.
Edge vs Node: Pick one framework from your matrix. In three bullets, explain when you would avoid running DB queries on the edge runtime for that stack.

C. Communication & governance

ADR: Write a one-page Architecture Decision Record: “Why we chose framework X for product Y” including rejected alternatives and a review date.
Stakeholder: Explain “single system” to a PM in five sentences without jargon—then rewrite with technical terms for an engineer.
Risk register: List five operational risks of adopting a meta-framework (security, caching, upgrades, hiring, hosting). For each, name one mitigation you would implement in the first month.

Answers & guidance (self-check)

1. Diagram — ownership vs external

Framework typically owns: URL routing to your server code, server rendering pipeline, bundling of client JS, dev server, build integration, often deployment adapter for the vendor platform.
External: Payment processor API, primary database, email/SMS providers, identity provider (unless self-hosted), observability backend, CDN configuration outside your repo (sometimes managed by host).
In-between: Auth session cookies may be implemented in your app but secrets live in vault/env; CDN may be automatic on Vercel/Netlify but still a distinct network hop.

2. Six responsibilities that stay yours

Any six of: schema design/migrations; backup/restore; least-privilege DB credentials; authorization rules; audit logging; rate limiting/abuse prevention; PII handling & data retention; performance budgets; incident response; cost monitoring; secret rotation; accessibility QA; content governance.

3. Single-system vs SPA+API — steps & shared types

Single-system (conceptual): Browser event → client handler or form POST to same-origin server action/route → server validates → DB → response/revalidate → RSC payload or JSON → UI update. Shared Zod/schemas live in packages imported by both server and client bundles from one repo.
Decoupled SPA+API: Browser → fetch to API origin → API validates → DB → JSON → client state update. Shared types require a published package or OpenAPI codegen; easy to skip and drift.
Key contrast: colocation reduces cross-service versioning friction; decoupling can improve team autonomy if boundaries are strict.

4. Matrix — starter key (verify against current docs)

Framework	Rendering (high level)	Data / mutations	Deploy	Good fit
Next.js	SSR/RSC/static/ISR mix; App Router	Server Components, Route Handlers, Server Actions	Node serverless/self-host/Vercel patterns	Broad: marketing + app + dashboards
Remix	SSR-first, nested routing	Loaders/actions tied to routes	Node adapters	CRUD-heavy web apps, web standards style
Nuxt	SSR/SSG/ISR via Nitro pipeline	Vue composables, server routes	Static + server targets	Vue teams, universal apps
SvelteKit	SSR/SSG/prerender options	`+server` endpoints, forms	Adapters (node/vercel/etc.)	Svelte teams, fast islands of logic
Astro	Static + islands	Mostly static; islands per framework	Static hosts	Content sites, docs, marketing

5. Research

Grading yourself: you should cite specific version numbers, link to release notes, and articulate impact (e.g., “deprecated X”, “improved cold start”).

6. Edge vs Node

Typical reasons to avoid edge DB: incompatible driver, need for long-lived connection pools, compliance region pinning, heavy ORM features unsupported at edge, unpredictable latency to primary DB.

7. ADR

Must include: context, decision, alternatives rejected with rationale, consequences (positive/negative), review date, and optionally owner.

8. Stakeholder

PM version: one codebase deploys the screens and the secure server logic; fewer handoffs; faster features; still need security reviews.
Engineer version: monolithic deploy unit with shared modules, same-origin cookies, framework-owned routing/rendering lifecycle, colocated route.ts/RSC boundaries.

9. Risk register — example mitigations

Security: mandatory authz checks in server modules, dependency audit in CI.
Caching: document revalidation strategy; add cache-busting tests.
Upgrades: pin versions; read migration guides; schedule quarterly bumps.
Hiring: internal guild sessions + starter templates.
Hosting: load tests on preview envs; DB pooler configured.

<< 2.17 Overview