JOVANA
Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Frontend, backend, and the line between

Every website is really two halves working together — the part you see and tap, and the part that hums away on a server — and here is how they split the work and talk to each other.

Every site is really two halves

Open any website and it feels like one single thing sitting in front of you. But behind that smooth surface, almost every site is split into two cooperating halves, and learning to see the seam between them is one of the biggest 'aha' moments in becoming a developer.

The first half is the frontend: everything you can actually see and touch. The buttons, the colors, the text, the little spinner while something loads — all of that lives in your browser, running on your own device. When people say 'the frontend,' they mean the part of the site that shows up on screen.

The second half is the backend: a program running on a server — another computer, somewhere out in the world — that you never see. It does the heavy, behind-the-scenes work: checking your password, saving your order, fetching the real data. The frontend is the face; the backend is the brain working quietly out of view.

The shopfront and the storeroom

Picture a small shop. At the front is the shopfront — the bright window display, the shelves, the friendly counter. Customers wander in, look around, point at what they want. This is the frontend: designed to be seen, welcoming, and easy to use. Its whole job is to look good and make asking for things effortless.

Out of sight, behind a door marked 'Staff Only,' is the storeroom — shelves of real stock, the safe, the ledger of who bought what. Customers never walk in there. This is the backend: it holds the valuable, sensitive things and does the actual work, but it stays locked away from the public.

The split isn't an accident — it's protection. You'd never let a customer wander into the storeroom and help themselves to the safe. In the same way, you keep the real data and the important decisions on the backend, where no visitor can reach in and meddle. The frontend can ask, but only the backend can act.

How the two halves talk

So the frontend in your browser needs something the backend has — say, your list of recent orders. How does it ask? It doesn't barge into the storeroom. Instead, it calls the backend's API: a clearly-labeled service counter the backend opens up on purpose, so the outside world has an approved way to make requests.

An API has many counters, and each one has its own address called an endpoint — a URL like /api/orders. You go to the right endpoint the way you'd queue at the right window in a post office: one for stamps, one for parcels. The frontend picks the endpoint that matches what it needs and sends its request there.

And what language do they speak across that counter? Almost always JSON — a tidy text format of labeled values that both computers and humans can read. The frontend sends a small JSON request, and the backend answers with JSON too. It's the shared paper slip both sides fill in and pass back and forth.

--- frontend asks the API at this endpoint ---
GET /api/orders

--- backend answers in JSON ---
{
  "orders": [
    { "id": 1, "item": "Tea", "price": 4 },
    { "id": 2, "item": "Mug", "price": 9 }
  ]
}
The frontend asks at the /api/orders endpoint; the backend replies with JSON it can display.
  1. You click 'My Orders' in the browser — that's the frontend reacting to you.
  2. The frontend sends a request to the backend's API at the /api/orders endpoint.
  3. The backend gathers the data and sends it back as JSON.
  4. The frontend reads that JSON and paints your orders onto the screen.

Where the data really lives

There's one more piece behind the backend: the database. This is where the real information is stored for keeps — every user, every order, every password — sitting safely on disk so it survives even when the server restarts. If the backend is the storeroom, the database is the locked filing cabinet inside it.

Here's the important part: the user — and the frontend — never touch the database directly. The frontend can't reach into that filing cabinet. It can only ask the backend nicely through the API, and the backend decides what to fetch, what to allow, and what to keep hidden. Every request passes through the backend's counter first.

Why so strict? Because the database holds everyone's secrets, not just yours. If the frontend could reach it directly, anyone clever enough could read other people's passwords or quietly change prices. By forcing every request through the backend, you keep one trusted guard standing between the public and the vault.

Putting it together

So now you can see the whole shape of a website. The frontend is the shopfront in your browser — everything you see and click. The backend is the storeroom on a server — where the real work and the real data stay safely out of reach.

Between them runs a clear line of communication: the frontend calls the backend's API at a named endpoint, and they trade tidy JSON messages back and forth. Behind the backend sits the database, the locked cabinet that no visitor ever opens directly.

Hold on to this map. As you keep learning, almost every new topic — login, forms, payments, live updates — is just another conversation crossing the same line between these two halves. Once you can see the line, the whole web starts to make sense.