Frontend vs backend: what each part of your app does

What is the difference between frontend and backend?

Think of a café. The frontend is what the customer sees: the menu, the tables, the counter, how the order is presented. The backend is the kitchen, stockroom and accounts: making the coffee, checking there is milk, recording the sale. The customer never enters the kitchen, but everything they receive passes through it.

Illustration

Apps work the same way. The frontend runs on your device, in the browser or a mobile app: pages, buttons, forms. The backend runs on a remote server: it calculates, checks and saves. Between them, messages travel back and forth in fractions of a second.

We will use one example throughout: a small coffee store you build yourself. If you are learning how apps are built, this article completes what a database is and how login works.

What does the frontend do in your store?

The frontend owns the customer's experience: how the store looks, how they move through it, how comfortable ordering feels. In the coffee store it:

• Shows products with photos and prices, in a grid on a computer and a single column on a phone.
• Manages the cart as you add and remove items, showing an instant estimated total.
• Shows forms for name, mobile and address, and warns you about a missing field before you send.
• Adapts to language: right to left in Arabic, left to right in English.
• Feels fast: a loading indicator, an "Added" message, smooth transitions.

But there is one thing the frontend does not do: have the final say. Anything that runs on the user's device can be tampered with. That is why we need the second part.

What does the backend do?

The backend is the kitchen and the accounts in one. The customer never sees it, but it decides what is true. In the coffee store it:

• Calculates the final total from the saved prices, not from the number the browser sent.
• Checks stock before accepting the order, and reduces it afterwards.
• Checks permissions on every request: is this customer the owner of this order? Is this staff member allowed?
• Saves data to the database and reads it back.
• Handles payment: sends the amount to the payment provider and confirms success before confirming the order.
• Sends messages: the sign-in code, the order confirmation, the alert to staff about a new order.

How do the two parts talk to each other?

Through requests and responses. The frontend sends a request, such as "this customer wants to check out this cart", and the backend answers "done, order 1024" or "sorry, that product is sold out". The set of requests the backend understands is called an API, explained in what an API is.

1. 1
   1The customer presses "Place order"

   The frontend gathers the cart and address and sends them to the server, along with the customer's session.

2. 2
   2The backend checks

   It verifies the session, reads the real prices from the database and checks stock.

3. 3
   3The backend acts

   It calculates the total, saves the order and its items, reduces stock and requests payment if needed.

4. 4
   4The response returns

   The backend sends back the order number and final total, or a clear error message.

5. 5
   5The frontend shows it

   The customer sees "Thank you, your order is 1024" and the cart empties.

All of this usually happens in under a second. And you can watch this journey yourself in your app's code, as the last section explains.

Where should each rule live in an app?

Everyone who builds an app faces this question, and the rule is simple: comfort goes in the frontend, correctness and security in the backend, and sometimes both. Pick a case to see where it goes:

When you review your app's plan, look for these decisions. If a price or a permission is decided only on screen, ask for it to move to the backend.

What about the database and hosting?

Two parts do not complete the picture. Behind the backend sits the database, which keeps everything; only the backend talks to it, and the browser never reaches it directly. Then there is hosting, the place where the server runs and the app's pages are served from. Deployment means putting the app there so people can reach it.

Frontend

Runs on the user's device: a browser or a mobile app

Backend

Runs on the server: calculates, checks and saves

Database

The app's memory, which talks only to the backend

Hosting

Where all of it runs and where people reach it

Domain

The address people type to reach your app

When someone says "full-stack developer", they mean a person who works on all of these parts. In Fanann hosting comes with the app, with the option of a Middle East region, and you can connect your own domain. Details on the hosting page.

How does Fanann build both parts together?

Traditionally an app needs a frontend developer and a backend developer, or one full-stack developer, who agree on the shape of the requests between the parts. In Fanann you describe the app in your own words, and the Fanann Agent builds the frontend, backend and database together, tests them, and shows you in plan mode what goes into each part before it starts.

When you want to change the look, use the visual editor: click any element and say what you want. That is a frontend change. When you ask "refuse orders under 30", that is a backend change. Noticing the difference is an excellent exercise.

Should I learn frontend or backend?

If you are thinking about a career: people who love looks, experience and interaction details lean frontend; people who love logic, data and security lean backend. But do not choose before trying both on a real app. Build yours in Fanann (the project is yours to open and export), then try:

The frontend makes promises; the backend keeps them. A good app never promises what its backend cannot deliver.

For the full path to understanding apps from the inside, go back to learn programming by building apps and how to read your app's code as a beginner.

Frequently asked questions

Terms in this article