Frontend and backend are the two halves of one piece of software: the frontend draws the screen on the visitor’s device, the backend holds the records and rules on a server. Which half a rule is written into is settled by one question: must the same answer come out the same for everyone? Resterm’s heater selection software runs that engineering calculation on the server, not on the screen.
Put those two names side by side in a proposal and the useful question is not which half matters more. A rule placed in the wrong half still looks correct on screen, and the mistake only shows up once there is a second surface to compare it against. What follows explains what each half does, then works out which half a rule belongs in using work that is already live.
One half runs on the visitor’s device, the other on a server
What separates the halves is where the code runs. Frontend code is sent down to the visitor and executes there, so the browser that opens your page assembles it and the app on a phone draws its own screens. Backend code never reaches the visitor at all: it sits on a server and runs there. Hosting is not the point of that difference. Authority is.
Code running on somebody’s own device shapes what that one person sees, while code running on a server produces the answer that has to hold for everyone. When two people ask the same thing and the answers have to match, the thing producing them cannot live on either device. No device gets to be the authority on a matter that involves other people.
Holding records is also only half of what the backend does, because it decides who may read which record. Permission cannot be settled in the frontend: the frontend runs on the visitor’s own machine, and nothing running there can hand itself a privilege. A screen is able to hide a field. It is not able to stop the field from being read.
The English names are the ones you will actually meet, in proposals, in job adverts and in how developers talk to each other, so this article keeps them. One phrase in the definition undersells the work, though. Drawing the screen sounds ornamental, and it is not: the frontend is the surface that collects input, showing fields, flagging the one still empty, splitting a long form into steps, holding an open filter open. Everything in that list belongs to one visitor’s current session and goes when the session goes.
Two line items on a proposal, two sides of one application
Pricing frontend and backend on separate lines invites one particular misreading: that two systems are being bought. The split names a division of labour. It does not name a pair of products.
Diotek’s climate and ventilation site, which carries its brochure pages and two request flows in one place, makes that visible. The marketing pages, the pre-sale survey booking form and the service call form all sit inside a single Laravel application. Moving from one page to the next happens on the visitor’s device, while what gets published at which address, and whether a submitted form is accepted at all, stays on the server. It is one application.
Separate servers come from the same misreading. Two halves need not live on two machines. An application’s frontend is the portion of what that application produces that executes on the visitor’s device, and nobody has to rent a second machine for that to be the case. The reason the halves are costed apart is duller than it looks: they are two different jobs, one building the screen and one enforcing the rule. Reading which job landed on which line is part of reading a proposal, and a line that counts screens is not hiding a rule.
Keeping the boundary physical helps. What sits on the visitor’s device is the screen’s current state: the open tab, the fields already typed, the filter currently selected. Close the tab and the state goes with it. Reopen it and the screen gets rebuilt, and what it reads while rebuilding is the record on the server.
There is a limit on that last sentence, and it comes back further down. The record does not stay on the server in every job.
Which half holds the rule: Resterm keeps no calculation on the screen
Definition gives way to decision here. Beneath anything software actually does sits a rule: which price applies, which product fits, which request can be accepted. Where the rule is written is not a stylistic call. It sets how far the answer can be trusted.
Resterm’s heater selection software, which sizes a heater from a stated requirement, shows that at its clearest. Nobody types a catalogue code into it. The input is the heating requirement of the space being heated. Shift the starting point like that and the screen’s job shifts with it: no search surface, just the description of a need. Which heater meets the need is decided by an engineering calculation, and the calculation runs on the server. Two jobs are left for the screen: take the requirement, show the product that came back. Nowhere on the screen is the selection rule written. The screen carries the output and none of the rule.
The payoff turns up in whoever writes the quote. Preparing a quote is usually not the same person’s job as sizing the heater, and because the rule lives in one half, somebody who cannot run the calculation still reaches the same heater from the same stated requirement. Write the rule onto the screen instead and every surface ends up with a copy of its own, with nobody able to promise the copies still agree over time.
The counter-case comes out of the same project. Feed it a product code and the screen’s job would have been search, with no selection rule to place in either half. A division is only a decision where a rule exists. Ask a ruleless catalogue which half holds the calculation and the question has nothing to attach to. So the order for your own work runs the same way: establish that you have a rule, then find where it sits.
The price that moves on screen and the price that goes on record
Speed muddies this more than anything else. Watch a demo answer the instant you touch it and the obvious conclusion is that the work happens right there.
The KGM SsangYong online sales channel, where each trim and colour pairing has a record of its own, really does answer that fast. Pick another trim, or another colour, and both the figure and the photograph of the car refresh with no visible delay, on the visitor’s own screen. The displayed value is not produced on that device, though. Every pairing of trim and colour is recorded on the server with a price, an image and a sales condition attached to that pairing alone, and all the screen does is choose which record to show. Nothing is calculated there; the screen reads an answer that was written in advance.
The boundary makes the split easiest to see. If the catalogue never defined a pairing, it cannot be assembled on a visitor’s screen. Every pairing within the visitor’s reach is reachable because a record for it exists. What the frontend can show is set by the backend, which is not a constraint of screen design but a question of whether the record exists.
Mistaking speed for authority costs something, and it costs it at the moment you decide what to buy. Ask not how fast a screen responded but where the displayed value came from. Two systems can behave identically at that speed, one reading the value off a record and the other working it out on the screen. In the second, one car can show up at two prices on two surfaces, with nothing in the system able to name the valid one.
Turn the case around and the same question gives a different answer. Where price sits on a single product record, a screen can be just as quick with no separate pairing record behind it. Off-the-shelf cart software runs on exactly that assumption, treating everything sold as one catalogue row, and that is the point at which it stops working once a product structure needs pairings. So the question was never whether the screen does the arithmetic. It is whether the thing being sold has a record.
If the page does not reload, which half did the work
No behaviour inflates the frontend’s reputation like this one: you change a filter, the list refreshes, the whole page stays put.
Plastik ve Makina, a classifieds platform where new and used plastics processing machines sit side by side, treats that as a design condition. Reloading the whole page on every filter change cuts the search apart, so the list was built with that in mind. What changes is the area the list occupies: the rest of the page holds still and only that region fills with new content. That is the part a reader sees, and the frontend’s share of the work ends there.
Which listings match an open filter is answered on the server. MySQL holds the listing records, and a Redis cache carries the load of the reads requested most often. Deciding whether a machine matches the filter is not the visitor’s device’s job; placing the answer it receives into the right part of the screen is.
The real subject of this section is two claims getting collapsed into one. That the page did not reload is one claim. That the frontend made the decision is another. The filter opens and closes in the frontend; the answer to it forms on the server. A smooth screen tells you nothing about an authoritative one. Nor is the filter merely a display switch: new and used ride the same axis, which is how a buyer compares them inside one search. That makes the filter part of the question being put to the list, raised on one side and answered where the records are.
Surfaces where only the frontend really works do exist; the article on replacing printed catalogues and menus with software has one. The measure holds either way: if what changes on screen is content that already reached the device, the work stays in the frontend, and if a new answer is needed, the decision moves.
The line does not run through the same place in every job
Every section up to here has left the record on the server. That sentence is not a definition.
AlgoKlima’s field app, which keeps working where network coverage stops, is where it gives way. AlgoKlima is our own product; it is live and we keep extending it. A technician out of coverage opens a service job on site and closes it when the work is done. The queue on the phone itself is what takes the record, and the app does not stop to look for a signal. So for a while the record lives in the frontend, on a phone that holds the only copy of it, and it stays that way until coverage returns.
What order the queue leaves in afterwards, and how an edit from the field meets an edit from the office in one record, belongs to a separate subject, covered in the article on field apps that keep working with no connection.
The consequence runs back into the definition. Saying records live on the backend is shorthand for assuming a connection is always there. The sentence works while the assumption holds. Once it fails the line moves, and the frontend becomes the record’s only holder for as long as that lasts. Learning the split as a list of definitions is therefore not enough; you have to know which assumption the list was written under.
A second detail sits in the same product. One surface is a panel the office opens in a browser, the other an app on the technician’s phone. Both are frontends, and both read the same customer and the same equipment record. Halves do not stop at two, then: surfaces can multiply while ownership of the rule does not. The screen is what gets divided. This article does not settle where a record lands first. That is one of the decisions made before any code is written, and it is the subject of system architecture work, where what a record attaches to is settled first.
Which half holds which work: four surfaces side by side
Set the same question against four industries and the location of the rule becomes comparable. Each row is live work; the three questions are the same in each.
| Work | On the device | On the server | Which half holds the rule |
|---|---|---|---|
| Sizing a heater from a stated requirement (Resterm) | The requirement is entered; the selected heater is read off the screen | The engineering calculation runs, picks a suitable electric heater, and the selection goes on record | Backend; no selection rule is written on the screen |
| Configuring a car and its price (KGM SsangYong online sales) | Trim and colour are chosen; the figure and the image refresh without delay | Each pairing keeps its own price, image and sales condition in its own record | Backend; the frontend draws what the record says |
| Listings and the condition filter (Plastik ve Makina) | The filter opens and closes; the region holding the list is refreshed | Listings matching the filter are prepared; MySQL holds the records, Redis carries the cache | Backend; the question that selects the list is answered there |
| A service job opened out of coverage (AlgoKlima) | The job is opened and closed, and waits on the phone | Once connectivity returns the record reaches the server; the office panel reads the same equipment record | Split; the record’s first home is the frontend, its lasting one the backend |
The last row stands apart from the other three, and it says split deliberately. No one-way rule is being imposed. The rule usually turns out to be written in the backend, and that follows from the conditions rather than from any law. What the first three share is an answer that does not vary with who asked: the same heating requirement, the same trim and colour pairing, the same set of filters, each needing the same answer on every surface. The last row turns instead on whether a connection exists at that moment, not on who owns the rule.
That leaves you one job: find the row your own business sits closest to. A rule that is the same for everyone puts you in the logic of the first three. Work that happens where coverage stops puts the last row in front of you.
The test: does the same answer have to come out the same everywhere
All of it reduces to a single question: does the same answer have to come out the same on every surface and for every person?
Answer yes and the rule goes on the server. At Resterm the same stated heating requirement has to pick the same heater for every user, which is why the calculation lives in one place; put it in the frontend and each surface ends up with a copy, with no way to tell whether the copies still agree. The KGM SsangYong channel makes the same point with a different kind of record. On its online sales channel the sales condition attached to a trim and colour pairing does not vary by visitor, so two people opening the same pairing on two devices meet the same condition, because a record is what they are looking at.
Plastik ve Makina runs the same test from the screen side. There, the listings a filter returns are bound to the same rule for every visitor. Opening and closing the filter is screen work; answering the filter is record work. Sharing a screen does not put them in the same half.
The test’s clearest written form inside one project is at Diotek, where the validation rules for two request types are kept in one place, so the type distinction never reaches the code running on the visitor’s device. That mechanism is unpacked in the article on booking a survey and logging a service call as separate records; here it stands as the test in working form.
The test says no as well. Work that shapes only what the one person currently looking at the screen sees belongs in the frontend: the display order of a list, which tab of a panel is open, how many steps a long form is broken into. None of those answers has to be defended to anyone. They are preferences about one person’s reading comfort. AlgoKlima sits on the edge of the test, since a record can stay in the frontend for a while, and not because ownership of the rule changed hands. It stays because there was no connection. So the test needs a second question beside it: is this work always done with a connection present?
Run the rule in your own business through that one question. If the answer is yes, where that rule is written is the first thing to settle in a proposal. In web development work, where the brochure pages and the parts that do the work come together in one application, that is the answer we go looking for before anyone draws a screen.
