The frontend runs in the user’s browser: HTML, CSS, JavaScript. It cannot securely store secrets, cannot directly access your database, and cannot do work that must be trusted (e.g. "user paid" or "user is logged in"). The backend is code that runs on a server you control. It receives HTTP requests, runs logic (auth, validation, business rules), talks to databases or external APIs, and returns HTTP responses. The browser only sees the request and response; it never sees your server code or database.

A simple backend might be a single process that listens on a port (e.g. 3000), has a few routes (e.g. `GET /` returns a page, `POST /api/contact` saves a message), and maybe uses a database or file for storage. That is enough to turn a static site into a dynamic, full stack app.

When the browser sends `GET /about`, the server looks at the path and method and chooses a handler (a function). That handler might read a template, query a database, or call another service; then it returns a response (status code like 200, headers, and a body—HTML or JSON).

Routing is the mapping from (method, path) to handler. For example: `GET /` → home page, `GET /api/users` → list users (JSON), `POST /api/users` → create user. The backend framework (Express, Fastify, Django, Spring) provides a router so you write something like `app.get("/", (req, res) => res.send(...))` instead of parsing raw HTTP yourself.

Back-end flow: request to response

Inside a handler you have access to request (method, path, query params, headers, body) and you produce a response (status, headers, body). You read the body (e.g. JSON for API, form data for forms), validate it (required fields, types, bounds), then run business logic and write the response. Never trust the client: validate and sanitize every input; use parameterized queries for the DB to avoid injection.

Side effects: Handlers can read/write the database, call other APIs, send emails, or enqueue jobs. Keep handlers focused: one route, one responsibility. If logic grows, move it to a service layer so routes stay thin and testable.

HTTP status codes tell the client what happened: 2xx success (200 OK, 201 Created), 4xx client error (400 Bad Request, 401 Unauthorized, 404 Not Found), 5xx server error (500 Internal Server Error). Return the right code so the frontend can show the right message or retry. For APIs, also return a body (e.g. JSON with `{ error: "message" }`) so the client can display it.

Consistency: Use the same error shape across your API (e.g. `{ code, message, details }`). On the server, catch exceptions, log them, and return 500 with a generic message—never leak stack traces or internal details to the client. Full stack means both sides agree on how errors are represented.

The backend process runs on a host: your laptop (development), or a cloud VM, container, or serverless function (production). It listens on a port (e.g. 3000). In production, a reverse proxy (Nginx, Caddy) or load balancer often sits in front: it receives requests on port 80/443, terminates TLS, and forwards to your app on 3000. So the "simple" picture is: browser → server:3000 → your code; the "real" picture is often browser → proxy → server:3000 → your code.

Environment: Use environment variables (or a secrets manager) for database URLs, API keys, and config. Never hardcode secrets. The same code can run in dev (e.g. SQLite, port 3000) and prod (PostgreSQL, behind a proxy) by changing env.

Frontend: Renders UI, handles user input, sends requests (e.g. `fetch("/api/data")`). It can validate input for UX (instant feedback) but must never be the only validation—a user can bypass the frontend and call your API directly. Backend: Validates every input, enforces auth and authorization, performs business logic, talks to the database, and returns only what the client is allowed to see. If the backend trusts the frontend, an attacker can forge requests and bypass checks.

Rule of thumb: Every piece of data that must be trusted (payment, identity, permissions) is decided on the backend. The frontend is a convenient way to build requests; the backend is the source of truth.

A simple backend is a running process that listens on a port, maps (method, path) to a handler, and in that handler you read the request (body, headers, query), validate input, optionally talk to a DB or external API, and send back a response (status, body). Once you have that, you have the core of full stack: the frontend can call your routes and you can add auth, database, and more routes over time.