Frontend and Backend, Plus the Database, Explained Simply

The frontend is the part of an app the user sees and touches: screens, buttons, forms. The backend is the part on a server that decides what is allowed and does the work. The database is where everything is kept while nobody is looking.

You will hear “frontend and backend” in every conversation with developers, and without a feel for where the line sits, it is hard to understand why something leaked, slowed down or broke. The easiest way to explain it is to follow one request through all three parts.

Frontend and backend in action: booking a class

Say you run an app for a yoga studio. Someone opens the schedule, picks Thursday’s class and taps “Book”. Here is what happens next.

1. Frontend. Code in the browser (usually React or something like it) draws the button and catches the tap. It gathers what needs to be sent, which class was chosen, and sends a request to the server along with proof of who is logged in: a session token.

POST /api/bookings
Authorization: Bearer <session token>
{ "classId": 42 }

2. Backend. The server receives the request and starts asking questions. Who is this? Is the token genuine and still valid? Does class 42 exist? Are there free spots? Is this person already booked? Has their membership hit its booking limit?

3. Database. To answer, the backend reads the class, the booking count and the membership from the database. If everything checks out, it adds a row to the bookings table: this person, this class, this time.

4. Back again. The backend replies to the frontend: “booked” or “class full”. The frontend shows a green tick or an error message. The whole round trip takes a fraction of a second.

Why the rules live in the backend

The one thing to remember: the frontend belongs to the user. Anyone can open the browser’s code, change it and send any request they like, bypassing your buttons. So the frontend can hide the “Book” button when a class is full, but the backend has to decide it.

If the “are there spots left” check exists only in the frontend, someone with a browser console can book a full class. If the membership price comes from the browser, they will pay whatever they type. The general rule: anything involving money, permissions or other people’s data is checked on the server.

What if there is no backend?

Many vibe coding tools, such as Lovable, Bolt and v0, build apps where the frontend talks to the database almost directly, through Supabase or Firebase. It looks as if there is no backend at all.

There is one, just in a different shape: access rules inside the database (in Supabase that is Row Level Security) plus server functions for anything you cannot trust a browser with. Without those rules, the database answers any request from anyone, exactly like a server that checks nothing. This setup is convenient while the app is small. Once you add payments, complex checks or external APIs with secret keys, you almost always need a proper backend.

Where it usually breaks

• Logic only in the frontend. Checks, limits and prices live in the browser, and the server saves whatever arrives.
• Secrets in the frontend. A paid API key is baked into code every visitor downloads.
• Too many requests. The frontend loads the list of classes, then asks for the booking count of each one separately. Unnoticeable with ten classes; a minute-long page load with a thousand.
• A database without structure. Everything sits in one table with a “data” text field, and every report turns into archaeology.

Knowing the three layers helps you ask the right questions: “is this check on the server or in the browser?”, “where does the frontend get this price from?”, “who can read this table?”.

In short

• The frontend is what users see; the backend is the server that checks and executes; the database is where data is stored.
• Every action is a request from frontend to backend, which reads from and writes to the database and sends back a response.
• The frontend belongs to the user, so permission checks, limits and prices belong in the backend.
• If the frontend talks to the database directly, database access rules play the backend’s role, and without them your data is open.

SUBXCAT can help you find where that line sits in your app and move to the server whatever should not live in the browser.