Frontend vs Backend: What's the Difference?
The frontend is what users see in the browser; the backend runs on a server and handles data, logic and security. How the two fit together, with an example.
Mythex Team · · 5 min read
The frontend is the part of an app that runs in the user's browser — the pages, buttons, forms and animations they see and click. The backend is the part that runs on a server the user never sees: it stores and retrieves data, applies the business rules, checks who's allowed to do what, and talks to other services like payments and email. The two communicate through an API, and together with a database they make up a "full-stack" app.
Why it matters when you build with AI
When you describe an app to an AI builder, you're describing both halves at once, whether you realise it or not. "Customers can book a slot" means a booking form (frontend), rules about which slots are free (backend) and somewhere to save bookings (database).
Knowing the split helps in three practical ways:
- Security. Anything in the frontend can be seen and changed by the user. Rules and secrets have to live in the backend.
- Debugging. "The button doesn't respond" and "the button responds but nothing is saved" point to different halves, and saying which you're seeing helps the AI find the cause faster.
- Hosting and cost. A frontend-only site is cheap and simple to host. A backend has to run somewhere, which affects what you pay and how your app behaves when idle.
An everyday analogy
Think of a restaurant.
The frontend is the dining room: the menu, the tables, the décor, the waiter taking your order. It's designed for customers and they can see and touch all of it.
The backend is the kitchen and the office: the chefs cooking, the stock room, the till, the manager's rules about who gets a discount. Customers never go in there, and they shouldn't be able to.
The API is the pass between them — the counter where orders go in and plates come out, in an agreed format. The database is the stock room and the order book.
A customer can rewrite their order slip (the frontend is under their control), but the kitchen still decides what it will cook and what it charges. That's why the important checks belong in the back.
What each side does
| Frontend | Backend | |
|---|---|---|
| Runs on | The user's device, in the browser | A server you (or your host) control |
| Main job | Show things, collect input, respond to clicks | Store data, apply rules, enforce permissions, call other services |
| Can users see and change the code? | Yes — it's downloaded to their browser | No |
| Can hold secret API keys? | No | Yes, in environment variables |
| Common technologies | HTML, CSS, JavaScript/TypeScript, React, Vue, Svelte, Tailwind | Node.js, Python (FastAPI, Django), C#, Java, Go, Ruby |
| What goes wrong | Layout breaks on mobile, button does nothing, slow page | Data not saved, wrong data shown, errors, security holes |
Some frameworks blur the line. Next.js, for example, lets one project contain both browser code and server code. The idea stays the same: the question is always where does this piece run?
A worked example: booking a class
Here's what happens when someone books a yoga class, step by step.
| Step | Where | What happens |
|---|---|---|
| 1 | Frontend | The schedule page loads and asks the backend for this week's classes. |
| 2 | Backend | Reads classes and bookings from the database, calculates spaces left, returns the list as JSON. |
| 3 | Frontend | Shows each class with time, teacher and spaces left. |
| 4 | Frontend | The user picks a class and fills in name and email. The form checks the email looks valid (a courtesy, not a guarantee). |
| 5 | Frontend → Backend | Sends a POST /api/bookings request through the API. |
| 6 | Backend | Validates the input again, checks the class isn't full, saves the booking, and asks the email service to send a confirmation using a secret key. |
| 7 | Backend → Frontend | Returns "booked" or "sorry, it's full." |
| 8 | Frontend | Shows the confirmation screen. |
Notice steps 4 and 6: the input is checked twice. The frontend check gives instant feedback; the backend check is the one that actually counts, because a determined user can bypass the frontend entirely.
Common terms explained
| Term | Meaning |
|---|---|
| Client / server | The client is the browser (or app) making requests; the server answers them. |
| UI | User interface — the screens and controls. |
| API | The agreed way the frontend asks the backend for data or actions. |
| Endpoint | One specific URL on the API, like /api/bookings. |
| Full stack | Frontend + backend + database together. See what a full-stack app is. |
| Static site | A frontend with no backend of its own; the same files for everyone. |
| SPA | Single-page application: a frontend that updates the page in the browser instead of loading new pages. |
| Server-side rendering (SSR) | The server builds the page's HTML before sending it, which can help speed and SEO. |
| Environment variables | Settings and secrets given to the backend at runtime, kept out of the code. |
Does your app need a backend?
| If your app… | Backend needed? |
|---|---|
| Shows information that's the same for everyone | No |
| Has a contact form that only emails you | Usually a small one, or a form service |
| Saves data other people will see | Yes |
| Has logins and private data | Yes |
| Takes payments | Yes — at least to create checkouts and receive payment webhooks |
| Uses a paid AI or other API with a secret key | Yes, to keep the key off the browser |
Common mistakes and misconceptions
- Putting secret keys in the frontend. It will be visible to anyone who opens the browser's developer tools. This is the most common serious mistake in AI-built apps.
- Enforcing rules only in the frontend. Hiding the "delete" button for non-admins isn't protection; the backend must refuse the request.
- Assuming the backend is "just the database." The database stores data. The backend decides who can read and change it and how.
- Thinking JavaScript means frontend. JavaScript and TypeScript run on servers too, with Node.js.
- Blaming the wrong half. If the page looks right but data is wrong, the problem is usually in the backend or database, not the design.
- Over-building. A portfolio doesn't need a custom backend. Adding one adds cost and moving parts.
What to ask your AI builder for
- "Which parts of this app run in the browser and which on the server?"
- "Move any API keys to the backend and read them from environment variables."
- "Validate every form on the server as well as in the browser."
- "Enforce on the backend that only admins can delete bookings."
- "The page looks fine but the data isn't saved — check the backend logs for the request."
- "This is a simple marketing site; keep it frontend only unless we need a backend."
Frontend and backend in Mythex
A new Mythex project starts from a Vite, React, TypeScript and Tailwind frontend, and the agent adds a backend when your app needs one — or you can ask for a separate API in Node, Python (FastAPI), C# or Java running alongside the frontend in the same project. In the preview you can switch between the website and the API server, and publishing deploys both, with a database and file storage added when needed. The docs explain multi-service apps, the web hosting guide covers where each half runs once live, and the app templates are a quick way to see full-stack examples.
Questions
What is the difference between frontend and backend?
The frontend is the part of an app that runs in the user's browser — the pages, buttons and forms they see. The backend runs on a server the user never sees; it stores data, applies business rules, checks permissions and talks to other services.
Does every app need a backend?
No. A marketing site, portfolio or simple landing page can be frontend only. As soon as an app needs to save shared data, log users in, take payments or use secret API keys, it needs a backend of some kind.
Is HTML frontend or backend?
HTML, CSS and JavaScript running in the browser are frontend. JavaScript can also run on a server using Node.js, where it's backend code. The language doesn't decide it; where the code runs does.
What does full stack mean?
Full stack means covering both the frontend and the backend (and usually the database). A full-stack app is one that has all three parts; a full-stack developer works on all of them.