Stop 01 · Web & Internet FoundationsTopics · 9/10

Browsers vs Servers

Part of the Full Stack Developer Roadmap

In short

As a full stack developer you write code for two very different computers. One sits in your user's hand, the other sits in a data centre. Mixing them up causes most beginner security bugs.

Understanding what actually runs where — the browser executes your frontend JavaScript and renders HTML/CSS; the server runs your backend code, talks to the database, and returns data or HTML.

The mascot hands a packet across a shop counter, with a stocked storeroom behind.

Think of it like this

The shop counter and the back godown

At a kirana shop, customers see only the counter. The stock, the cash box and the price register stay in the godown at the back. The browser is the counter anyone can lean over. The server is the godown only staff can enter.

Watch it happen

Who runs what in your app

Browser

  • Renders HTML, CSS and React
  • User can read every line
  • Never store secrets here

Server

  • Runs Node.js and talks to the DB
  • Code and keys stay hidden
  • Has the final say on rules

Put looks and interactions in the browser. Put data, secrets and anything that must be trusted on the server.

The big ideas

What you need to know

Browser code is public

Anyone can open DevTools and read, pause or change your frontend JavaScript. Treat it like a poster on a wall.

Secrets live on the server

Database passwords and payment keys belong in server environment variables, never in a React file that ships to users.

Server checks are the real ones

A disabled button in the browser is a hint. The server must check again, because anyone can call your API directly.

Same language, two places

JavaScript runs on both sides, but the browser has window and document, while Node has the file system and network sockets.

See it in code

Walk through the code

js
1// Runs in the BROWSER (public, user can edit it)2document.querySelector("#buy").addEventListener("click", async () => {3  const res = await fetch("/api/orders", { method: "POST" });4  console.log(await res.json());5});6 7// Runs on the SERVER (private, Node.js + Express)8app.post("/api/orders", async (req, res) => {9  const user = await getUserFromSession(req);10  if (!user) return res.status(401).json({ error: "Login first" });11  const order = await db.order.create({ data: { userId: user.id } });12  res.status(201).json(order);13});

1/3Browser code reacts to a click and sends a request. Anyone could fire this same request from a terminal.

The browser only asks. The server decides who the user is and writes to the database.

Save yourself the pain

Common mistakes

Oops

Putting an API secret key in a React component because it is 'hidden in the bundle'.

Do this instead

Everything in the bundle is downloadable. Keep keys on the server and call your own API instead.

Oops

Checking the price only in the browser before checkout.

Do this instead

Calculate the final price on the server from the database. Browser values can be edited in seconds.

Your mission

Spot the two computers

~15 min

Quick check

Your React app hides the 'Delete user' button for non-admins. Is the delete route safe now?

Go deeper

  1. 1List what code in a typical request runs in the browser vs on the server.
  2. 2Learn why some code, like database credentials, must never run in the browser.
  3. 3Understand server-side rendering blurs this line — some 'frontend' code actually runs on the server too.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge