Frontend · Backend
Frontend / Backend
What is frontend?
- Frontend = the screen users see
- Back end = data and logic behind the scenes
- The two halves of web development
The first thing that changes once you separate front end from back end is where incident reports land. Even a one-line complaint like “My order won’t go through” calls for different people depending on whether the button never responded or it was pressed and the server rejected it. In practice, a 30-second look at the Network tab (press F12 in the browser) settles it, and whether the request reached the server is the first fork. Take the wrong direction and the wrong team burns days.
The boundary between the two usually sits at an agreement point called an API. The frontend agrees in advance on “we’ll send these values to this address,” and the backend on “we’ll reply in this format,” so each side can work independently, even to the point where two different companies build the screens and the server at the same time. Response codes are also a clue: 400-series codes usually point to a problem on the request side, 500-series codes on the server side. Someone who handles both is called a full-stack developer, but that means not that they do everything alone, but that they can hold a conversation across the boundary.
When you outsource work, this split also becomes the unit of the quote. Write “18 screens and 24 APIs” instead of “one online store,” and the schedule and staffing can be calculated, and at mid-project check-ins you can see which side is falling behind. The backend and the infrastructure that runs servers and networks (DevOps) are a different matter, though. An outage where the site simply won’t load is often a server capacity or domain configuration problem rather than a code problem, so some issues come in that are not worth calling a developer about in the middle of the night.
The assumption that causes the most mix-ups in the field is “slow screen = front end’s fault.” Many slow-loading lists are caused by database queries that take several seconds, and shrinking images or stripping animations won’t change how fast it feels. Vibe coding has the same trap: you ask the AI for just the screens, get a convincing mockup and pass the demo, but it’s an empty shell where entered data vanishes on refresh. If a purchase order lists only the number of screens and leaves out where data is stored and who validates it, you end up redoing the schedule and budget from scratch right before launch.
Jaryong KooMarketing PhD and authority in AI, data analytics, and personal branding
John KimAuthor of B2B Marketing Design and CEO of Nanum Consulting| Category | Front end | Back end |
|---|---|---|
| Role | The screen users see | Data and logic processing |
| Location | Browser or app (front end) | Server (behind the scenes) |
| Yes | Buttons, layout | Login, database, payments |
As the web grew more complex, the roles of “presenting the screen” and “handling data and logic” were divided, and the distinction settled in naturally. It took shape in everyday web development practice rather than coming from any one originator.
Consider a hypothetical case: Company A, a household-goods distributor with 140 employees and annual revenue of about KRW 48 (≈ US$1) billion, redesigned its online store over a three-month schedule. Within two weeks of launch, customer service was logging 30 reports a day that “items won’t add to the cart,” while the outsourced developer and the operations team traded “our side is fine” and let two weeks slip by.
- When Assistant Manager Kim on the operations team opened the Chrome DevTools Network tab and clicked “Add,” the cart API returned a 500 error, and within 30 minutes it was clear the problem was on the server side, not the screen.
- When the outsourced firm’s back-end developer dug through the logs, the inventory lookup query was averaging 4.2 seconds and timing out. Assistant Manager Kim said, “So those two weeks I spent on CSS were completely wasted.”
- The DX team lead overhauled the outage report form to make a screenshot and the Network tab status code required fields, and set it up so each report is automatically assigned to either the frontend owner or the backend owner as soon as it comes in.
- The back-end developer added an index to the inventory table, cutting lookup time from 4.2 seconds to 0.3, and the front-end developer reworked the screen to show a “Processing” indicator when responses are slow.
- A month later, cart-related inquiries had dropped from 30 a day to 2, and the time it took to pinpoint the first cause of an outage fell from an average of 2 days to 40 minutes.