What it is
The frontend is the part of a product the user touches. In a web app that means HTML and CSS plus JavaScript, often via React, running in a browser or a WebView. The backend is code you run on a machine you control: an Express or Next.js server, a Python API, a database, a queue. The browser talks to the backend over HTTP (REST APIs for Application Development, sometimes GraphQL or WebSockets).
"Full stack" means one person works on both. It does not mean there is one process with no boundary. Even a Next.js app has a server side and a client side. The boundary is where trust changes.
Why and when it is used
Split frontend and backend so you can update the UI without exposing the database, and so you can have more than one client (web, mobile) on one API. Put anything secret or authoritative on the backend: API keys for model APIs, database credentials, the decision of whether this user may see this row. The frontend can hold a short-lived session and the pixels.
A purely static frontend is fine for a brochure. A backend with no UI is fine for a job that runs on a schedule. Do not invent a backend for a page that never sends data. Do not put the database connection string in the frontend because it was faster.
How it works
The frontend renders state and sends requests: "create this draft", "stream a reply". The backend authenticates the caller, checks authorisation, reads or writes the database, calls other services, and returns JSON or a stream. The frontend then renders the result. Validation happens in both places: the UI for fast feedback, the server because the UI can be skipped. Anyone can send a request with curl.
Authentication answers who is calling. Authorisation answers what they may do (Authentication versus Authorization). A pretty frontend check that hides a button is not authorisation. The server must refuse the request. Sessions or tokens (JWTs, cookies) are how the server recognises the same user on the next call.
Technologies and dependencies
A UI stack, an API stack, a database, and a way to develop them together (two ports on localhost, or one framework that hosts both). CORS appears when the browser UI and the API have different origins. Environment Variables configure the backend. The frontend build may receive a public API base URL, which is not a secret. CI should build and test both.
How to get started
- Draw one user action: "save a note". Write the request and the response on paper.
- Implement the backend route first. Call it with curl. Reject an unauthenticated call.
- Implement the smallest UI that sends that request and shows success or the error string.
- Move the model API key, if you have one, to the backend. The browser calls you; you call the model.
- Add one authorisation rule (a user can only read their notes) and a test that uses two users.
- Only then improve the visual design.
If you are alone, you can still keep the folders separate. Future you is a second developer.
Cautions and trade-offs
Trusting the client is the architectural bug. Prices, permissions and prompts that must stay private do not belong in frontend code. Shipping a "temporary" key in the bundle becomes an incident.
Over-splitting too early (a dozen microservices for one form) is the other failure. One backend process is a good start. Also beware of duplicating business rules only in the UI. When a mobile app appears, those rules vanish. Put them on the server. Finally, streaming AI responses are still this architecture: the backend holds the key and forwards tokens. The frontend is a view over a stream, not the place that owns the model.