What is Backend Development?

What is it?

When you use an app — say, a shopping site — a lot of what you see and click happens right there in your browser: buttons animate, forms validate as you type, pages update instantly. But some things can't safely or sensibly happen on your device. Charging your credit card, checking whether an item is actually in stock, deciding whether your password is correct — these need to happen somewhere the user can't peek into or tamper with, and somewhere that can talk to a shared database that every user's app depends on.

That "somewhere else" is a server: another computer, usually sitting in a data center, that your app's browser code sends requests to over the internet. The code that runs on that server — deciding what to do with a request, reading and writing shared data, enforcing the rules of the business — is called the backend. The part running in the user's browser, by contrast, is the frontend.

A backend typically does a few recurring jobs: it stores and retrieves data (usually in a database), it applies business logic ("can this user actually cancel this order?"), it talks to other systems (payment providers, email services), and it decides what to send back to whoever asked.

Explain like I'm 10

Think of a restaurant. The dining room — the menu, the table, the person taking your order — is the frontend: what you directly see and interact with. The kitchen is the backend: it's where the actual food gets made, the fridge (database) gets opened, and decisions get made about substitutions or what's out of stock. You never walk into the kitchen yourself; you send a request through a waiter and wait for a response.

Examples

A frontend action that needs a backend

// In the browser (frontend): the user clicks "Place Order"
button.addEventListener("click", async () => {
  const response = await fetch("https://api.shop.com/orders", {
    method: "POST",
    body: JSON.stringify({ itemId: 42, quantity: 2 }),
  });
  const result = await response.json();
  showConfirmation(result);
});

The browser can't safely check stock levels or charge a card itself — it sends a request to a server and waits for an answer.

What the backend does with that request

// On the server (backend): receiving that same request
app.post("/orders", async (req, res) => {
  const { itemId, quantity } = req.body;
  const item = await db.items.findById(itemId);

  if (item.stock < quantity) {
    return res.status(400).json({ error: "Not enough stock" });
  }

  const order = await db.orders.create({ itemId, quantity });
  res.status(201).json(order);
});

This code never runs on the user's device — it lives on the server, where it can be trusted to check real, shared, up-to-date data before deciding what happens.

How it works

A backend is just a program, like any other, except it's designed to sit and wait for incoming requests rather than to be opened by a user directly. It listens on the network for messages, does some work when one arrives (read a database, run a calculation, call another service), and sends a message back. It keeps running continuously, serving many different users' requests, often at the same time.

Why does it exist?

Some things simply cannot be trusted to code running on a stranger's device: that code can be inspected, modified, or bypassed entirely by anyone with a browser's developer tools. Backends exist to keep sensitive logic, shared data, and trust boundaries in a place the business actually controls — a server it owns or rents — rather than in the hands of every individual user.

When to use it

Any time an app needs to store data that outlives a single visit, needs to enforce a rule that a user shouldn't be able to bypass, needs to keep a secret (like an API key or password hash), or needs multiple users to see the same shared state, that logic belongs on a backend.

When not to use it

Purely visual behavior — animating a menu, validating that a text field isn't empty before the user even submits, remembering a UI preference for just this one session — doesn't need a round trip to a server. Doing everything on the backend when nothing shared or sensitive is involved just adds needless network delay.

Common mistakes

• Assuming that because a rule is enforced in the frontend's JavaScript, it's actually enforced — a user can bypass frontend code entirely.

• Believing 'backend' means one specific technology — it's a role a program plays, not a single language or framework.

• Putting secrets (API keys, database passwords) into frontend code, where anyone can view them, instead of keeping them on the server.

Practice exercises

1. Easy:

   List three things a shopping app's backend needs to do that its frontend cannot safely do alone.

2. Medium:

   Explain, in your own words, why checking a discount code's validity should happen on the backend rather than in the browser.

3. Hard:

   Describe what could go wrong if a banking app calculated your account balance entirely in frontend JavaScript instead of on a backend.

Interview questions

What is backend development?

Building the part of an application that runs on a server: business logic, data storage, and communication with other systems, as opposed to the frontend, which runs in the user's browser.

Why can't sensitive business logic be trusted to run only in the browser?

Browser code executes on the user's own device, where it can be inspected, modified, or bypassed entirely using developer tools — so anything that must be trusted, kept secret, or checked against real shared data needs to run on a server the business controls instead.

Give an example of something that must happen on a backend, and explain why.

Charging a payment: it requires a secret API key for the payment provider and must use the real, current price and order total, none of which can be safely handed to or verified by code running on the customer's own device.

What's the core difference between a frontend and a backend in terms of where the code executes and who controls that environment?

Frontend code runs on the user's own device, inside an environment the user (or anyone with dev tools) fully controls; backend code runs on a server the business owns or rents, so only the business can inspect or change it.

Why does checking whether an item is "in stock" need to happen on a backend rather than in the browser?

Stock is shared data that every user's app depends on and that changes as other people buy the item — a browser only has whatever data it was last given, so only a backend talking to the live, shared database can give an accurate, trustworthy answer.

Using the restaurant analogy, why does a customer never walk into the kitchen themselves?

The kitchen represents the backend, where the actual work happens on shared resources like the fridge (the database); letting customers directly control it would mean no consistency or trust, so requests are routed through a waiter (the network request) instead.

Why is it incorrect to say "backend" refers to one specific language or framework?

Backend describes a role a program plays — handling requests, applying business logic, and managing shared data — not a technology choice; that role can be filled by Node.js, Python, Java, Go, or many other stacks.

A backend trusts a `role: "admin"` value sent by the frontend in the request body to decide access. What's wrong with this?

Anything sent from the frontend can be edited by the user before it's sent, so trusting a client-supplied role field lets any user grant themselves admin access; the backend must instead look up the user's actual role from its own trusted, server-side data (like a session or database record).

Why does validating a form field in frontend JavaScript still have value even though it isn't a real security measure?

It gives the user immediate feedback without a network round trip, improving the experience — but the backend must repeat the same validation itself, since the frontend check can be bypassed entirely.

What risk does hardcoding a database password directly into frontend source code create?

Frontend code ships to and runs on every user's browser, where its full source is visible via developer tools; embedding a secret there exposes it to anyone who looks, effectively publishing that password.

If two users try to buy the last unit of an item at the same moment, why must the stock check happen on a shared backend rather than in each user's own browser?

Each browser only knows its own local, possibly stale view of stock; only a backend talking to one shared, authoritative database can see both attempts and correctly allow just one of them to succeed.

What does it mean for a backend to "enforce a rule the user shouldn't be able to bypass," and why can't that same rule live only in frontend code?

It means the rule is checked somewhere the user can't tamper with or skip — frontend code runs entirely under the user's control, so any check placed only there can be disabled, edited, or ignored by directly calling the backend without going through the frontend at all.

Why does a backend typically need access to a shared database, while a purely frontend app usually doesn't?

A backend serves many users who all need to see and affect the same underlying data (orders, inventory, accounts); a frontend only needs to display and collect data for the one user currently using it, which it gets by asking the backend.

Name a UI behavior that doesn't need a backend round trip, and explain what makes it safe to keep client-side only.

Animating a menu opening, or checking that a text field isn't empty before the user submits — these affect only the current user's own screen, involve no shared data, and reveal or risk nothing if done entirely in the browser.

Why is "the frontend already validated this" never a safe assumption for backend code to make?

A request can reach the backend without ever going through the intended frontend at all — via a tool like curl or Postman, or a modified version of the app — so the backend must independently validate anything it can't afford to get wrong.

Beyond "it's more secure," why must charging a credit card run on a backend rather than in the browser?

Charging a card requires a secret merchant API key that must never be exposed to users, and needs to use the real, server-verified order total rather than whatever amount the browser happens to send.

What's the practical consequence of a backend being the one thing every user's frontend talks to, rather than each user running their own private copy of the logic?

It means there's exactly one place enforcing the rules and one shared source of truth for the data, so all users see consistent results — a fix or rule change made once on the backend applies to everyone immediately, without updating every user's device.

Why might a backend also be described as running on "a server," and is that a specific machine?

"Server" describes the role of continuously listening for and responding to requests, not a particular piece of hardware — it could be a physical machine in a data center, a virtual machine, or a container, as long as something is running the backend program and reachable over the network.