What Runs on the Client and on the Server

The problem

Frontend architecture gets messy when teams mix client and server responsibilities without a clear rule.

Then you start seeing fetches inside components that should not even know about data loading, business rules leaking into the browser, and the client recalculating work the server could have sent ready.

The result is a slower, more fragile, and more tiring codebase.

Mental model

Client and server are not just different locations.

They have different jobs:

• the server fetches data, enforces hard rules, protects secrets, and prepares the heavy truth
• the client handles immediate interaction, local state, clicks, typing, and fast UI feedback

Once that split becomes clear, architecture decisions get much easier.

It also becomes easier to avoid two classic problems at once:

• making the browser do too much work
• leaking sensitive rules where they do not belong

Breaking it down

Before deciding where logic should run, answer these questions:

1. Does this logic need an API secret, direct database access, or strong permission checks?
2. Does this logic depend on clicks, typing, or immediate visual feedback?
3. Could this heavy transformation happen on the backend so the browser does not pay that cost?
4. Does this business rule really need to be exposed in the client bundle?

These questions stop you from mixing environments out of convenience.

They also help avoid a common trap: deciding where code lives just because that component file already happens to be open.

Simple example

Imagine a dashboard that shows recent orders and lets the user filter by status.

A clean split looks like this:

• the server fetches the orders, formats the dates, and sends a ready initial payload
• the client receives the list, stores selectedFilter, and updates the screen when the user interacts

A common mistake is pushing everything to the client: fetching raw rows, formatting data, applying business rules, and rendering the UI there too.

That increases CPU cost in the browser and erases the boundary of who should do what.

Another common example is authorization.

You can hide a button in the client to improve UX.

But the real permission check still needs to live on the server. If the sensitive rule only exists in the browser, it is not protecting anything.

Common mistakes

• pushing browser-side transformations that the server could do better
• leaving API secrets or sensitive rules too close to the client
• treating an interactive React app as an excuse to make the client do everything
• deciding where code lives based on file convenience instead of architectural responsibility

Another recurring mistake is sending data that is too raw and expecting every screen to rebuild the useful version by itself. That usually spreads rules around and duplicates work.

How a senior thinks

More experienced engineers do not start by asking:

which file should hold this function?

They ask:

which side of the network should own this responsibility so the interface stays fast, secure, and simple?

That question improves performance, security, and maintenance all at once.

Seniority shows up here in treating the boundary as a responsibility decision, not just a framework detail.

What the interviewer wants to see

In frontend system design interviews, this shows maturity quickly.

• You understand that client and server work together but play different roles.
• You can justify why logic belongs on one side and not the other.
• You prioritize security, simpler networking, and less browser cost.

A strong answer often sounds like this:

I try to keep on the server everything that depends on secrets, strong permission checks, database access, or heavy transformation. On the client, I keep what needs to react quickly to clicks, typing, and local UI state. That reduces bundle cost, avoids leaking rules, and keeps the interface simpler.

The client exists to interact. The server exists to prepare and protect the truth.