A full stack framework combines frontend (UI, routing, state) and backend (API routes, server logic, often DB access) in a single project and deployment. You write components and API handlers in one repo; the framework handles build, routing, and how the server and client connect. Examples: Next.js (React + Node), Remix (React + Node), Django (Python, server-rendered templates or API), Rails (Ruby), Laravel (PHP).

Benefits: one language and one codebase for both sides, shared types and validation, built-in patterns (SSR, API routes, env handling), and a single deploy. You trade some flexibility (e.g. mixing any frontend with any backend) for speed and consistency.

Next.js is React on the front with a Node server. You get file-based routing: `app/page.tsx` → `/`, `app/api/users/route.ts` → `/api/users`. API routes are server-side; they can use secrets, talk to a DB, and return JSON. Pages can be client-rendered (default in `app/` with "use client"), server-rendered (async component that runs on the server), or statically generated at build time. You can mix: some pages SSR, some static, some client-only.

Data flow: A page can fetch data on the server (no separate API call from the client) or the client can call `/api/...` with `fetch`. Next.js also supports middleware (runs before the request hits a page or API), so you can do auth, redirects, and rewrites in one place.

Django is Python-based and server-centric. You define models (DB schema), views (request → response), and templates (HTML with variables). The server renders HTML and sends it to the browser; optional Django REST Framework adds a JSON API for a separate frontend (e.g. React). So you can do "traditional" server-rendered pages or a decoupled SPA that talks to Django via API.

Comparison to Next.js: Django is more opinionated (admin, ORM, migrations out of the box) and great for content-heavy or form-heavy apps. Next.js is more frontend-first (React components, client interactivity) and fits JS-heavy products. Both are "full stack" but with different centers of gravity.

Next.js / Remix: When your product is highly interactive (dashboards, real-time, rich client state) and your team is comfortable with React and Node. Good for startups and products that need fast iteration and a single deploy.

Django / Rails: When you have lots of server-rendered pages, forms, and CRUD, or when your team prefers Python/Ruby and server-side templates. Good for content sites, admin tools, and APIs that serve multiple clients.

Separate frontend + backend: When you have multiple frontends (web, mobile) or multiple backends (microservices), or when you want to scale front and back independently. Then you pick a frontend framework (React, Vue) and a backend (Node, Go, etc.) and connect them via API.

In a full stack framework, the "seam" between front and back is either API routes (frontend calls `/api/...` like any client) or server components / server-side data (the server runs code and passes data into the page without a separate HTTP call). Next.js App Router encourages the latter for initial data (faster, no extra round trip); you still use API routes when you need client-triggered actions (form submit, refresh button) or when a separate client (mobile app) will call the same API.

A full stack framework typically has one build: the frontend is compiled (bundled, minified) and the backend is the same process or a sibling (e.g. Next.js outputs a Node server that serves both pages and API routes). You run one command (e.g. `next build && next start`) and deploy one artifact. Static assets can be served from a CDN while the server handles dynamic routes and API.

Env: The same repo often has one set of env vars: some are server-only (DB URL, secrets), some are exposed to the client (e.g. `NEXT_PUBLIC_API_URL`). The framework injects the right ones at build or runtime so the frontend never sees secrets. That single pipeline is a big win for speed and consistency.

Because front and back live in one repo (or at least one ecosystem), you can share types: define a DTO or schema once (TypeScript interface, Zod, etc.) and use it in both the API handler and the frontend. The API validates the request body against the schema and returns typed responses; the frontend uses the same types so you get autocomplete and compile-time safety. When you change the API contract, the type system helps you update the client. This reduces "contract drift" and makes refactors safer.