Frontend vs Backend: What Actually Has to Live on a Server?

The more features I add to an app, the more often I run into the same question: should this logic live inside the application, or somewhere on a backend?

At first I thought about frontend and backend mostly in terms of screens versus databases. The frontend displays things, the backend stores things. In practice, the boundary is much more useful when I think about trust.

Code running on a user’s phone or in a browser is ultimately under the user’s control. They can inspect network requests, modify local state and, with enough effort, inspect what has been bundled into the application. That means the frontend is a bad place for anything that must remain private or that the user should not be able to decide for themselves.

Displaying a recipe belongs in the frontend. Deciding whether someone is allowed to access a paid feature might require information from a trusted service. A public configuration value can live in the app; a private API key should not. A button can request that something happens, but a sensitive operation often needs to be validated somewhere the user cannot manipulate.

That gives me a fairly simple rule:

The frontend can ask. The backend decides anything that requires trust.

This does not mean every app needs a traditional server running somewhere. Firebase, serverless functions and managed APIs can handle a lot of backend work without me maintaining a machine myself.

The important part is not whether there is a physical server. It is whether important logic runs in an environment I control rather than one the user controls.