Frontend, Backend, and the Full Request Cycle

You have built the frontend — the code that runs in the browser. Now meet the rest of the machine.

The two halves of every site

• Frontend (client-side): HTML, CSS, JavaScript — downloaded to the user's browser and executed there. Everything from Modules 1–4 lives here.
• Backend (server-side): code on a server that responds to requests, applies rules, and owns the data. Users never see this code.

One click, end to end

When you press "Buy":

1. The browser sends an HTTP request — "POST /checkout" with your cart.
2. The server receives it. Backend code runs: check the session, validate the cart, compute tax.
3. The server asks the database — "save this order" — and waits.
4. The server sends back an HTTP response — status, and usually JSON.
5. The browser's JavaScript renders the confirmation.

All of that in a few hundred milliseconds, thousands of times per second, all over the world.

Where Code Journey itself fits

When you press Run on a challenge: your browser (frontend) posts your code to a Code Journey server (backend), which stores the job and hands it to a locked-down execution machine, then returns a verdict your browser displays. You have been using a full-stack application this whole time — now you can name its parts.

Why the split matters

The frontend can be modified by anyone (open DevTools — every value in it is yours to inspect). So trust lives on the server: passwords, prices, permissions. Any site that trusts the browser on important decisions gets broken within minutes. This single idea explains most security decisions you will ever encounter.

What you learned

• Frontend runs in the browser; backend runs on the server
• The request cycle: request → server → database → response → render
• Code Journey is itself a full-stack app you have been using
• The browser is untrusted territory — real checks happen server-side

Next: the protocol that carries it all — HTTP.