Front end vs back end: follow one click through the whole system

The front end is the part executed for the user, usually in the browser: structure, presentation, interaction, local validation and the display of known states. The back end is the server-side part that receives requests, applies shared rules, controls access, coordinates data and returns a response.

A hidden browser calculation is still front end. A server-generated page that you can see is still produced by back-end code. Visibility is therefore a poor boundary; execution and responsibility are the useful ones.

A static site can deliver HTML, CSS, JavaScript and media without server-side application processing on every visit or storing modifiable business data. A portfolio, documentation site or campaign page may need no database and no custom API.

A back end becomes useful when the experience needs a shared truth: accounts, stock, permissions, payments, saved content, personalisation or coordination between users. Many products also combine static delivery with a small number of serverless or third-party services.

A click does not travel as a click. The front end interprets an event, reads the current form state, builds a request and changes the interface to acknowledge the action. From that point on, the product crosses several boundaries. Each boundary can succeed while the next one fails.

“Front end” therefore does not mean “single-page application”, and “back end” does not mean “database”. A back end can return HTML. A front end can contain complex local logic. An API can be owned by a separate team or shaped specifically for one interface through a backend-for-frontend.

The right architecture follows the constraints: how fresh the data must be, whether users share state, what must work before JavaScript, where latency occurs, which team operates the system and how failures are recovered. Framework names come after these questions.

PHP is a server-side language. The browser does not download the PHP source and does not execute it. A web server routes the request to the PHP application; PHP reads the request, calls the required code, may query a database or another service, then produces a response. The browser receives the result — often HTML or JSON — without receiving the server program that created it.

For the fictional booking, JavaScript can react to the button and send POST /bookings. PHP can authenticate the visitor, validate the workshop identifier, start a transaction, verify the remaining capacity, record the booking and associate the operation identifier with the result. It then returns a status such as 201 Created, 409 Conflict or an existing booking for a recognised retry.

Modern PHP applications are not limited to full-page reloads. The same codebase can render an accessible first page, answer JSON requests, process background jobs and expose command-line tasks. Frameworks can organise routing, dependency injection, validation and persistence, but the fundamental lifecycle stays readable: request in, rules applied, response out.

PHP is a strong choice when a team values mature hosting, server-rendered content, a broad ecosystem and direct integration with relational data. A site delivered as static files does not need to execute PHP on every visit, although PHP may still generate those files beforehand. It is not automatically the best answer for every real-time or compute-intensive workload. The decision belongs to the product’s constraints and the team that will operate it.

MySQL is a relational database management system. It stores structured data in tables, links records through keys and can enforce rules that must remain true even when several requests arrive together. PHP communicates with it through a driver such as PDO; the browser should never receive database credentials or connect directly to the production database.

A minimal booking model might separate workshop, booking and operation. The workshop carries its capacity. A booking links one person to one workshop. The operation stores the request identifier and the result already produced. Sending the same identifiable intent several times without creating several bookings is called idempotency. Names vary; the important point is that identity, relationships and uniqueness are explicit.

The browser can detect an empty email field, explain a format and avoid a needless round trip. That makes the interaction faster and clearer. It cannot prove that an email is authorised, that a price is legitimate or that stock still exists. Browser code and requests can be changed outside the intended interface.

The server must therefore validate every value that affects identity, permission, money, availability or stored data, and verify authorisation on every request. It should reject by default, expose only the data required by the caller and return errors that are useful without revealing secrets. The front end then turns those errors into recovery: correct a field, sign in, choose another slot or check an operation already in progress. OWASP Authorization Cheat Sheet (opens in a new tab).

A user experiences one duration, but engineers need a decomposition. Time can be spent before the request leaves, in connection setup, at a gateway, in application code, waiting for another service, querying data, transferring the response or rendering the new state. Optimising the wrong segment may change a laboratory score without changing the delay people feel.

The simulation deliberately compresses queues, caches, gateways, authentication, distributed databases and third-party services into four stages. Its purpose is to reveal responsibility and uncertainty, not to reproduce a production stack.