Frontend vs backend: which half of your app is which?

What it actually is

Every web app is split in two. The frontend is the part that runs in your visitor’s browser: the HTML, CSS, and JavaScript their browser downloads when they open your site, which becomes the pages, buttons, and forms they interact with. The backend is the part that runs on a server: a program that waits for requests, talks to your database, and decides what each user is allowed to do. The two halves talk over the network, usually through an API endpoint.

Think of a restaurant. The dining room is the frontend: menus, tables, everything customers see. The kitchen is the backend: customers never walk in, and it holds the recipes, the stock, and the actual cooking. A diner can scribble a lower price on their copy of the menu, but the register in the back still charges the real one.

That last point is the one that matters most. The frontend is public: every visitor gets a full copy of your frontend code, because their browser needs it to render the page. Right-click, View Page Source, or open the Sources tab in dev tools, and it’s all there. So nothing in the frontend can stay secret, and nothing the frontend checks can be trusted, since any visitor can edit the page live in dev tools. Secrets and rules belong on the backend, the only half a stranger can’t open.

Why your AI just did this

Your agent draws this line constantly. Ask it to “let users save their notes” and it announces it needs a backend: a browser can show a form, but keeping data after the tab closes takes a server and a database. So it scaffolds an endpoint, maybe suggests Supabase, and your one-sentence feature now spans both halves.

The same line is why a good agent refuses to paste your OpenAI key into a React component. Frameworks make the boundary explicit. Vite only ships environment variables whose names start with VITE_ into browser code, and its docs warn that those must never hold API keys. Next.js does the same with NEXT_PUBLIC_: prefixed values get baked into the JavaScript sent to every visitor, while everything else stays on the server. When your agent says a key “needs to move server-side,” it’s carrying a secret from the public half into the private half.

When you’ll run into it

Debugging splits along the same line. Frontend errors land in your browser’s console (F12, Console tab): Uncaught TypeError, Failed to fetch, red lines pointing at .js or .tsx files. Backend errors land in your server logs, which live on your hosting provider’s dashboard, not in the browser. The browser only sees the aftermath, like a 500 Internal Server Error with no explanation. Paste only the browser side to your agent and you’re handing it half the evidence.

The classic symptom is “the page looks fine but nothing saved.” That means the frontend rendered and the backend call failed. Open the Network tab next to the Console and you can watch the two halves talk: each row is the frontend asking, each status code is the backend answering.

The tools you keep hearing about sort into halves too:

Tool	Which half	What it does there
React	Frontend	builds the interface from components, in the browser
Tailwind CSS	Frontend	styles that interface
Node.js	Backend	runs JavaScript on a server
Supabase	Backend	Postgres database, logins, file storage
Next.js	Both	React pages plus server code in one project

That last row is what “full-stack” means: one project, both halves. Money follows the split as well. Serving frontend files is cheap, since they’re static copies handed out on request, while backend compute and database storage are where hosting meters run.

What to check

• Open dev tools (F12), go to the Sources tab, and search your own site for any key you suspect got shipped; if you can find it there, every visitor can, and it counts as an exposed API key
• Ask your agent which half a change touches before approving it: “does this code run in the browser or on the server?”
• Treat any variable named VITE_something or NEXT_PUBLIC_something as public by definition, and keep real secrets in server-side environment variables
• Read both consoles when something breaks: the browser console for the frontend half, your host’s server logs for the backend half
• Enforce every rule that matters on the backend; hiding a button or validating a form in the frontend is comfort, and any visitor can bypass it in dev tools

Say it like a dev

Instead of: “the app looks fine but my stuff doesn’t save” Say: “The frontend renders, but the backend request is failing. Check the Network tab for the failing call and the server logs for what the endpoint returned.”

Instead of: “hide my API key somewhere in the code” Say: “Move this key out of the frontend bundle into a server-side environment variable, and have the frontend call our own backend endpoint instead.”

Instead of: “make sure only admins see the delete button” Say: “Hiding the button in the frontend isn’t enough. Enforce the admin check on the backend endpoint too, since anyone can call it directly.”