Step 4 of 23
what users see vs where work happens — and why it matters for decision-making
หน้าบ้านที่ผู้ใช้เห็น vs หลังบ้านที่ประมวลผล — ทำไมต้องแยก และกระทบอะไรบ้าง
Every piece of software has two sides. The frontend is the dining room -- what customers see, touch, and interact with. The backend is the kitchen -- where the actual work happens behind closed doors.
Diagram: The restaurant analogy mapped to software — dining room (frontend), kitchen (backend), and pantry (database) connected by order and data flows.
Loading diagram...
| Concept | Restaurant | Software |
|---|---|---|
| Frontend | Dining room, menu, decor, waitstaff | Buttons, layouts, forms, animations |
| Backend | Kitchen, pantry, chef, recipes | Servers, databases, logic, processing |
| Database | Pantry (where ingredients are stored) | Where data is stored and retrieved |
| Full-stack | Chef who also serves tables | Engineer who works on both sides |
The frontend is everything the user sees and interacts with. On a website, that means:
A good frontend is like a well-designed restaurant: inviting, easy to navigate, and clear about what to do next. A bad frontend confuses people. They leave.
Frontend engineers work with languages and tools built for visual presentation and user interaction.
The backend handles everything the user does not see:
When you click "Buy" on an e-commerce site, the frontend shows you a loading spinner. The backend is doing the real work: checking your payment method, reserving inventory, sending a confirmation email, updating the database.
The database is where information is stored -- user accounts, product catalogs, transaction history, everything. When the backend needs data (e.g., "what items did this customer buy last month?"), it goes to the database, retrieves the information, and sends it back.
A well-organized database is like a well-stocked, neatly labeled pantry. A poorly organized one means slow service and mistakes.
A "full-stack" engineer can work on both the frontend and backend. They understand the entire flow from user interaction to data storage. This does not mean they are better -- it means they are versatile. Most large projects still have specialists on each side.
When someone says "the site is broken," knowing which side is affected changes the conversation entirely:
Each problem requires a different team, a different fix, and a different timeline. Asking "is this a frontend problem or a backend problem?" immediately narrows the investigation.
