IT Literacy for Non-Developers #1: What Is a Website Made Of? — Frontend, Backend, and Database

IT Knowledge
7 min read

When you work on the same team as developers, there are moments when everyone is clearly speaking the same language, yet you have no idea what they mean. Phrases like “that’s a front-end task, so it’ll be quick,” “we need to touch the backend, so it’ll take a few days,” or “it’s not landing in the DB” are exactly those moments. For someone who writes specs, designs screens, or markets the service, these words are easy to hear every day but hard to truly understand.

This series is an IT literacy course for people who never write a single line of code. It isn’t meant to turn you into a developer. It’s meant to help you talk to developers accurately. Once you really understand a single term, you spend less time lost in meetings, you can report bugs precisely, and you start to grasp why schedules are set the way they are.

This series, IT Literacy for Non-Developers, consists of five parts.

  • #1 What Is a Website Made Of? — Frontend, Backend, and Database ← this post
  • #2 What Is an API?
  • #3 Servers, the Cloud, and Deployment
  • #4 Bugs, Hotfixes, and Rollbacks — How Developers Respond to Incidents
  • #5 Git and Version Control — How Many People Edit One Codebase

The first post has a single goal. It’s to help you grasp that the websites and apps we use every day are split into three layers — frontend, backend, and database — and to get a feel for what each layer does.

Behind the Screen, There Are Three Layers #

Even in the short process of searching for a product in an online store, adding it to your cart, and pressing the checkout button, three different parts are actually moving together. A restaurant analogy makes it easy to understand.

  • The frontend is the dining hall where guests sit. It’s everything the guest sees and touches directly, like the menu, the tables, and the staff serving them.
  • The backend is the kitchen. It’s where orders come in, dishes are prepared and sent out, and it’s invisible to the guest.
  • The database is the pantry and the ledger. It stores the ingredients and keeps a record of who ordered what.

The guest only sees the dining hall, but the dining hall alone can’t produce food. Websites work the same way. The screen is only part of the whole, and behind it two invisible layers are working together.

Frontend — Everything You Can See #

The frontend is the part that appears directly on the user’s screen. The color of a button, the size of the text, the motion of a menu unfolding, and the response when you type into an input field all fall into the frontend’s domain. It runs on the user’s computer or smartphone — more precisely, inside a web browser like Chrome or Safari.

The frontend is built from three basic materials. HTML lays out the skeleton of the screen, CSS adds color and shape, and JavaScript adds motion and responsiveness. This is exactly the part that designers and planners deal with most often. Requests like “please move this button to the right,” “please make the font bigger,” or “please add a loading animation” are mostly frontend work.

That said, not everything visible on the screen is the frontend. The content shown on the screen, such as a product price or a member’s name, is a result received from the backend. The frontend simply arranges that content nicely and displays it. This distinction is the starting point for understanding the next two layers.

Backend — The Brain That Makes Decisions Out of Sight #

The backend is the part that runs on a server, invisible to the user. It checks whether a password is correct when you log in, determines whether stock is available when an order comes in, calculates the payment amount, and verifies whether a user has the right permissions. It’s where the service’s rules and decisions gather, which is why it’s often called the business logic.

When the frontend reports “the checkout button was pressed,” the backend checks, one step at a time, “is this user actually logged in, is the balance or limit sufficient, is the stock still available,” and then decides whether to proceed with the payment or reject it. A large share of problems like “I can’t log in” or “the payment keeps failing” arise not in the screen but in this backend decision process.

Even for the same bug, the difficulty of fixing it varies greatly depending on which layer the problem is in. A frontend fix like changing a button’s color often wraps up quickly, but a backend fix like changing a payment rule is handled carefully, because if it goes wrong it can lead to problems involving real money. This is exactly why a developer says, “that’s backend work, so it’ll take some time.”

Database — The Warehouse That Remembers Everything #

With only the frontend and backend, one thing is missing. That thing is memory. Information that needs to be kept for a long time — member details, order history, posts, product lists — has to be stored somewhere. That storage is the database.

The database is easiest to picture as a giant Excel spreadsheet. In the member table, each row holds one person’s information, and in the order table, each row records one order. When needed, the backend pulls information out of these tables, writes new information in, and edits what has changed. When a user signs up, a row is added to the member table, and when they place an order, a row stacks up in the order table.

A problem like “I signed up yesterday, but today my information is gone” is closely related to the database. Unlike the temporary processing that happens in the browser or on the server, the database’s contents persist even when the power is off. Because every record the service has accumulated ultimately stays here, the database is also the layer handled most cautiously.

How a Single Click Passes Through Three Layers #

To see how the three layers move together, let’s follow a single login as an example.

  1. The user enters their ID and password on the screen and presses the login button. Up to here, this is the frontend.
  2. The frontend sends the entered values to the backend. To check whether this ID is an account that actually exists, the backend requests the member information from the database.
  3. The database returns that member’s stored information to the backend. The backend compares whether the entered password matches the stored value.
  4. If it matches, the backend returns a “login success” result to the frontend, and the frontend shows the user a welcome screen. If it doesn’t, it shows the message “the password is incorrect.”

With a single button press, the three layers conversed in turn. The agreement by which the frontend and backend exchange information here is called an API, and we’ll cover that part separately in the next post.

Why Knowing This Makes Your Job Easier #

Once you can tell the three layers apart, some things change right away in your day-to-day work.

  • You can report bugs precisely. If you write something like “the screen shows 1,000 won, but when I pay, 1,100 won is withdrawn,” the developer can suspect the backend’s calculation rather than the screen. A report that estimates which layer the problem is in greatly speeds up the resolution.
  • You develop a sense of timing. Once you know that the weight of a task differs depending on whether it’s a frontend fix or a backend fix, it’s easier to accept “why this takes a day and that takes a week.”
  • You don’t get lost in meetings. You can follow the main thread of the conversations developers have, and you can ask precise questions when you need to.

Wrap-Up #

In this post, we looked at the big picture: that websites and apps are made of three layers.

  • The frontend is the screen the user sees and directly interacts with.
  • The backend is the brain that, on an invisible server, judges and processes the rules.
  • The database is the warehouse that stores and records information for the long term.

These three layers don’t work in isolation. With every user action, they constantly talk to one another. What kind of agreement that conversation rests on is the topic of the next post. In the next post, we’ll look at what the API — a word developers keep on the tip of their tongues — really is.

X