Episode 2 — React Frontend Architecture NextJS / 2.17 — Understanding Full Stack Frameworks
2.17 — Interview Questions: Full Stack Frameworks
Pair with 2.17.a — What Are Full Stack Frameworks? (single-system mental model, responsibilities) and 2.17.b — Modern Landscape (how teams pick stacks in 2026).
Beginner
Q1. What is a full stack web framework?
Model answer: A framework that helps you build both the interactive web UI and server-side request handling (routing, APIs, server rendering, mutations) in one application system—usually one repo and one deploy pipeline—with shared modules for things like validation and types.
Q2. Does “full stack framework” mean the database is included?
Model answer: Typically no. You still connect to Postgres, MongoDB, or SaaS APIs. “Full stack” here means the web tier spans browser and server, not that the database ships inside the UI framework.
Q3. What is the difference between “single system” and “SPA + separate API”?
Model answer: A single system colocates UI routes and server handlers in one deployable app with one toolchain. SPA + API splits ownership across two services (even in a monorepo), which often implies separate versioning, CORS, and duplicate validation unless you invest in shared packages.
Q4. Name two things you still own when the framework gives you SSR and API routes.
Model answer: Data modeling and migrations, secrets rotation, authorization rules, observability (logs, traces, metrics), rate limiting, and incident response—the framework provides hooks, not product correctness.
Intermediate
Q5. Why do teams want “single system” instead of SPA + separate Node API?
Model answer: Fewer moving parts for a product team: one CI pipeline, shared validation and types, simpler cookie/session stories without CORS friction, and faster refactors when a feature touches both UI and server code. Trade-off: you must still enforce clear module boundaries so the codebase does not become a ball of mud.
Q6. What is a meta-framework? Give two examples.
Model answer: A framework built around a UI library (often React) that adds routing, server execution, and conventions—Next.js and Remix are common React-side examples; Nuxt does the same for Vue and SvelteKit for Svelte. You still write UI in the library, but the application shell is owned by the meta-framework.
Q7. How would you explain “inversion of control” for Next.js vs “plain React”?
Model answer: In plain React you choose where rendering starts and how data loads. In a meta-framework, the framework calls your modules (page.tsx, layout.tsx, route.ts) on a defined lifecycle. You extend the framework’s architecture instead of assembling all glue yourself.
Q8. What is Astro’s common sweet spot compared to Next.js?
Model answer: Content-heavy sites with mostly static HTML and islands of interactivity where you want minimal client JS by default. Next is often chosen when the product is a dense interactive app with deep server integration across many routes.
Q9. What is one real caveat when evaluating “edge-first” runtimes for data-heavy apps?
Model answer: Database drivers and TCP patterns differ from long-lived Node servers; cold starts, connection pooling, and latency to the primary database can dominate. You verify driver support and measure p95 before committing edge for DB paths.
Advanced
Q10. How would you compare frameworks in 2026 without sounding outdated next month?
Model answer: I anchor on durable axes: rendering model (SSR/RSC/islands), data mutation story, deploy/runtime (serverless vs long-lived Node vs edge), ecosystem/hiring, and operational maturity. I cite official docs and release notes for the pinned version we run. I avoid claiming a permanent winner—products and constraints differ.
Q11. When would you reject a full stack meta-framework?
Model answer: When the deliverable is a tiny embed, when the org mandates a different platform (legacy Java portal), when edge-only constraints conflict with our DB drivers, or when the team lacks capacity to learn caching and security implications. Another case: strict separate team ownership between web and API with hard org boundaries—though many orgs still use monorepos.
Q12. How do you talk about “vendor lock-in” honestly?
Model answer: Every stack has switching costs. Meta-frameworks couple you to routing conventions, rendering pipeline, and deployment assumptions. I quantify risk with portable boundaries: domain logic in plain modules, avoid framework-specific hacks in business rules, document external integrations, and schedule periodic re-evaluation against product needs.
Q13. A PM says “we must pick the most popular framework.” How do you respond?
Model answer: Popularity helps hiring and tutorials, but success depends on fit: SEO needs, auth model, content velocity, team TypeScript depth, and hosting constraints. I propose a weighted scorecard and a time-boxed spike (one vertical slice) before a long-term bet.
Quick-fire
| # | Question | One-line answer |
|---|---|---|
| 1 | Single system? | One web app boundary: UI + server handlers colocated |
| 2 | Main DX win? | Shared types/validation + one deploy story |
| 3 | Main risk? | Security/complexity if server treated casually |
| 4 | Nuxt pairs with? | Vue |
| 5 | SvelteKit pairs with? | Svelte |
| 6 | Astro common use? | Content sites + islands of interactivity |
| 7 | Edge caveat? | Driver + latency model differs from Node |
| 8 | Hiring lens? | Material density of learning resources varies |
| 9 | Remix mental model? | Web fundamentals + nested routes + forms/data |
| 10 | “Full stack” still needs? | Authz, schema migrations, SLOs, backups |
Answers at a glance (topic coverage for 2.17.a + 2.17.b)
Use this as a end-of-module cram block. Expand aloud in interviews using the model answers above.
| Topic (lesson alignment) | Answer you should be able to say |
|---|---|
| 2.17.a — Definition | Full stack web framework = unified browser UI + server execution in one app system; DB remains external. |
| 2.17.a — Why teams adopt | Velocity: shared validation/types, fewer network boundaries than SPA+API, simpler cookies for same-site flows. |
| 2.17.a — What you still operate | Identity, authz, data integrity, performance budgets, security reviews, on-call, cost controls. |
| 2.17.b — Meta-framework | Framework around a UI library adding routing/server conventions; examples: Next/Remix (React), Nuxt (Vue), SvelteKit (Svelte). |
| 2.17.b — Landscape axis: rendering | Compare SSR vs static vs islands vs RSC-style splits; pick by SEO + freshness + cost. |
| 2.17.b — Landscape axis: deploy | Serverless vs Node vs edge—match to DB proximity, cold start tolerance, compliance region. |
| 2.17.b — Product fit | Marketing/content → often static or islands; authenticated dashboards → server data + heavy client widgets; public SEO apps → SSR/RSC patterns. |
| 2.17.b — Decision hygiene | Scorecard + spike + ADR + review date; cite versioned docs, not blog hype. |