A website has three parts. The frontend is what visitors see and click in the browser; the backend is a program on the server that receives requests, checks data and decides what to answer; the database stores products, requests and users. A simple brochure site can live without a backend and database. Anything that has to “remember” data — a catalogue, a customer account, an admin panel — needs storage and server-side logic, but you do not have to write them from scratch: BaaS platforms such as Supabase or Firebase and external services with an API provide them, and one visitor’s settings can be kept right in the browser.
After this you will be able to
- Describe the path of one request: from typing an address and the DNS lookup to the server response and the browser assembling the page
- Explain what the frontend, backend and database are each responsible for, and why price and permission checks belong on the backend
- Tell a static site from a dynamic one and decide whether a site needs a backend and a database
- Use a checklist to confirm that the repository, hosting, database, admin panel and domain belong to the company
Contents
An analogy: a website works like a restaurant
Picture a restaurant. The dining room with its menu, tables and sign is the frontend — everything the guest sees. The kitchen, where guests never go, is the backend: that’s where orders are taken, ingredients are checked and dishes are cooked. The pantry and fridges are the database: everything the kitchen cooks with is stored there. The waiter carrying orders between the room and the kitchen is the request the browser sends to the server.
- 01Browser
- 02Server
- 03Database
The journey of one request: what happens after a click
Browsers and servers talk over HTTP: the browser sends a request, the server returns a response. That is how MDN — the developer reference maintained by Mozilla — describes the web. Here is what it looks like, step by step, when you open a catalogue page:
You type an address or click a link
First the browser finds out which server hosts the site: it uses DNS to turn the domain name into an IP address — the computer’s number on the network.
The browser sends a request
It asks the server for a specific page, for example “catalogue, armchairs section”.
The backend processes the request
The program on the server works out what is needed and asks the database for the list of armchairs with prices and stock.
The server sends a response
The response contains HTML: the page structure with links to CSS (styling), JavaScript (behaviour) and images. The browser fetches those files with further requests.
The browser assembles the page
It lays the files out on screen and you see the catalogue.
When you fill in a request form, the route is the same, only your data travels the other way: the browser sends it to the server, and the backend validates the fields and saves the request to the database or forwards it to a manager.
Frontend, backend and database: who does what
- 01FrontendThe interface in the browser: layout, buttons, forms, mobile adaptation
- 02BackendLogic on the server: data checks, access rights, calculations, links to other systems
- 03DatabaseStorage: products, orders, users, change history
Frontend
- What it does
- Shows information and takes the visitor’s actions
- Where it runs
- In the browser on the visitor’s device
- Example task
- Catalogue filter, cart, request form
Backend
- What it does
- Receives requests, applies business rules, sends a response
- Where it runs
- On the server
- Example task
- Check stock, calculate delivery, send a lead to the CRM
Database
- What it does
- Stores data reliably and finds it quickly
- Where it runs
- On a server, often a separate one
- Example task
- Keep orders, customers, prices
Frontend and backend are often written by different specialists and in different languages. A frontend developer makes sure the interface is clear, fast and works equally well on a phone and a computer. A backend developer makes sure data is saved without losses, business rules are followed and outsiders can’t reach other people’s information. On small projects one person may cover both roles, but these are still two separate areas of responsibility.
One important detail: anything that runs in the frontend can, in theory, be inspected and changed by the visitor in their own browser. That’s why checks that involve money and access — the price in an order, user permissions, discounts — must always run on the backend.
Static and dynamic websites
MDN divides websites into two types. A static site serves every visitor the same pre-built pages. A dynamic site assembles the page at the moment of the request — from a template and data in the database — so it can show each visitor something different.
Static site
- Pages are prepared in advance and identical for everyone
- No database — nothing on the server to “break”
- Fits a brochure site, landing page or portfolio
- New pages are added by a developer or a generator at build time
Dynamic site
- Each page is assembled from a template and data on every request
- Has server-side logic and data storage — its own or ready-made services
- Needed for a catalogue, customer account, booking, payments
- Content changes through the admin panel without a developer
In practice the line is blurry. Many modern websites build their pages in advance, like a static site, and connect the live parts — a request form, a cart, a delivery calculator — through a backend. Visitors get fast loading, and the business gets working forms and up-to-date data. The choice of approach depends not on fashion but on what the site has to do.
CMS and admin panel: how you manage content
A CMS (content management system) is software that lets you change texts, images and products without touching code. The admin panel is its workspace: a closed part of the site for staff, not visitors. Technically, the admin panel is also a frontend and a backend — just for your own team.
- Page texts, news and blog articles
- Products or services: names, prices, photos, availability
- Requests and orders from forms — with filters and statuses
- Banners, promotions, contacts and opening hours
- Admin users and their rights: who can only view and who can edit
A CMS can be off-the-shelf — installed on the site and configured — or built for the task. An off-the-shelf one fits when you mainly edit texts and news. A custom admin panel makes sense when the business has its own processes: requests go through several statuses, products are tied to a warehouse, managers have different rights. What matters most is that the admin panel is convenient for your staff, not just for the developer.
Where the code lives and what must belong to you
A website has several “homes”. The source code is kept in a repository — a version control system that records the full history of changes. A working copy of the code runs on hosting or a server. The database lives separately and needs regular backups. And the address everything opens at — the domain — is registered with a registrar. If even one of these places is held only by your contractor, you depend on them.
- The code repository is in the company’s account, with the contractor invited as a member
- Hosting or the cloud server is paid from the company’s card or account
- Access to the database and a clear place where backups are stored
- An owner account in the admin panel with administrator rights
- The domain is registered to the company, not to the developer
- A short guide on how to redeploy the site if the server has to change
A well-built website isn’t just a good-looking frontend. It’s also a clear kitchen, a reliable pantry and the keys to every door in the owner’s hands.
