The Four Layers
Frontend, backend, database, and the host — including a single-page app and a SQLite file.
Learning objectives
- Describe the four layers: frontend, backend, database, and host
- Classify an app by which layers it actually needs
- Spot a “frontend only” project that will need a backend the moment it stores anything
- Tell a single-page app from a multi-page site, and name SQLite as a real database
Four layers, in the order a request meets them
HTML, CSS, and JavaScript the browser runs. Buttons, forms, the class list.
A program on a server. It checks the request, applies rules, and talks to the database.
Durable records: accounts, bookings, class times. Survives a restart.
The machine, the disk, the process that stays running, the domain, and HTTPS.
The frontend is what a visitor can inspect in the browser. Anything secret — database passwords, admin rules, payment checks — does not belong there. The backend is the part that can see those secrets because visitors cannot read its files. The database is not “the backend.” It is where rows live. The host is not a layer of code. It is where the other three are allowed to run.
Two kinds of frontend
A multi-page site asks the server for a new HTML document every time you click. WordPress, Laravel, and a plain PHP form work this way. The browser’s job is mostly to show what came back.
A single-page application (SPA) loads one HTML shell and a JavaScript bundle. After that, clicks change the screen without a full reload. React, Vue, and the pages AI tools generate are usually this shape. The class list, the reserve button, and the admin view are all one program running in the browser. Data still comes from the server. An SPA is a frontend. It is not a stack by itself.
| Multi-page | Single-page app | |
|---|---|---|
| What a click does | Loads a new HTML page | JavaScript swaps the view. The URL may change without a new document. |
| Where the rules live | In the server program that built the page | Display rules in the browser. Booking rules still on the server. |
| What you notice in the repo | routes/web.php, templates, wp-content | src/App.jsx, a vite or react dependency, one index.html |
SQLite is a database that is a file
SQLite is a database engine you link into the app. There is no separate database server to install. The data is a file — often studio.db or dev.db — that the backend opens. For an MVP with one server process and a few dozen students, that file is enough. Bookings, class times, and the owner’s login can all live in it.
It is still a database. It has tables, SQL, and constraints. The limit is operational: one app process should own the file. Two copies of the app, or a disk that gets replaced on every deploy, will lose or split the bookings. Postgres and MySQL are separate programs you add when you outgrow the file. You do not need them to find out whether anyone wants the Thursday class.
Not every app has all four
| Product | Layers it needs | Why |
|---|---|---|
| A one-page studio brochure | Frontend + host | No accounts, no bookings. A web host can serve the files. |
| Workshop Co. MVP | SPA + one backend + SQLite + host | All four layers, but the database is a file the one server process opens. |
| Workshop Co. after it grows | All four, with a database server | Same product. Postgres replaces the file when more than one app process must write. |
| A chat tool with logins | All four, plus a process that stays up | Messages are data. Live updates often need a long-running program, not a PHP page that exits. |
| A WordPress site | All four, packaged together | Themes are the frontend. PHP is the backend. MySQL is the database. The host runs PHP and MySQL. |
The demo stores bookings in the browser (localStorage). It looks finished. The second person, on their own phone, does not see the first booking, because that data never left the first browser. A SQLite file on the server fixes that: both phones talk to the same process, and that process owns studio.db. A SQLite file that only exists on the laptop does not. The database has to be where the visitors are not.
Classify the app
The tool built a page that lists classes from a hardcoded array in a JavaScript file. The “Reserve” button only shows an alert. Which layers exist today, and which one appears the day reservations have to be real?
Answer
Today there is a frontend — likely a single-page app — and, once you upload it, a host that serves those files. There is no backend and no database. The day a reservation has to exist for every visitor, you add one backend process and a database. For the MVP that database can be a SQLite file the process opens. The host then has to run that process, not only hand out HTML.