Why frontend and backend exist as separate things

Published on 2026-09-12 by frfrand

No es una moda ni una forma de dividir tareas: son dos entornos con reglas incompatibles. Qué corre en cada lado, por qué nunca hay que confiar en el navegador y dónde va cada validación.

Many people hear "frontend and backend" and understand it as a division of labor: some do the visual part and others do the logic. It is true as a description of roles, but it falls short and leads to wrong decisions.

The real separation is deeper: they are two environments with incompatible properties.

The difference that explains everything

The frontend runs on someone else's machine.

That's it. Everything else follows from there.

The code you send to the browser is in the user's hands: they can read it, modify it, run it manually, or simply ignore it and send requests with another tool. There is no way to prevent it, because for it to work, the browser needs to understand what you sent it.

The backend runs on your server, where you control who enters and what is executed.

That is why anything that must be true must be decided in the backend.

The practical consequence

An example that repeats itself: a form that validates that the age is greater than 18. It is validated in the frontend so the user receives the notice instantly, without waiting for the server. Perfect.

And it also has to be validated in the backend. Not out of distrust towards that user: because the request can arrive without going through your form.

The short rule: validating in the frontend is a courtesy, validating in the backend is the rule.

The same goes for prices, permissions, stock, and discounts. If the browser sends "price: 0", the server has to ignore that data and look up the real price.

What lives on each side

Frontend: visual structure, styles, interactions, immediate validations, interface state, animations.

Backend: business rules, permissions, database access, integrations with external services, secrets.

That last word deserves emphasis. API keys, database credentials, and paid service tokens cannot be on the frontend. Not even "obfuscated": everything that reaches the browser is visible.

The boundary between the two: the API

The conversation goes through an explicit interface, normally HTTP with JSON.

That clear boundary is what allows the same backend to serve a website, a mobile app, and an automated process. And it allows the frontend team to redesign everything without touching the business logic.

It is also where it is worth being strict: the API should accept exactly what it needs and reject the rest, with clear error messages. A permissive API is comfortable the first month and a source of bugs forever.

When separation gets in the way

It is worth saying it, because the industry sometimes exaggerates. For a content site, separating into a frontend that consumes an API can be extra work without benefit: the server returns HTML already built and ready.

Separation pays for itself when there are multiple interfaces against the same backend, when the teams are different, or when the interface is very interactive. For a blog, no.

Where each thing lives on a server

In practice, both end up on the same machine more often than one might think: nginx serves the frontend's static files and, when the route starts with /api, it passes the request to the backend listening on a local port.

In ArduMaker, this distribution is configured from the panel: one repository can be deployed as a static site and another as a service, each with its own domain or path, on the same VPS or on different ones.