Yiuno

Backend

9 min read

Backend

The part of a software system that runs on the server, processes requests, applies business rules, and manages data — everything the user never sees.

What is the backend?

When you submit a form, search for a product, or log into a website, the frontend sends your action to a remote computer. That computer — the server — runs the backend: the code that decides what to do with your request.

The backend receives requests, processes them, and sends back responses. It is where the real work happens: querying databases, checking whether you are allowed to do something, applying business rules (like “you cannot withdraw more than your balance”), and assembling the data the frontend needs. The user never sees the backend directly — they only see its effects through the frontend.

If the frontend is what the user experiences, the backend is what makes that experience possible. A beautiful frontend with no backend is a brochure — it can show information, but it cannot remember anything, process anything, or respond to individual users.

In plain terms

The backend is the kitchen of a restaurant. The customer (user) never enters the kitchen. They place an order through the waiter (the API), the kitchen processes it using recipes (business logic) and ingredients from the pantry (database), and sends the finished plate back. The quality of the meal depends entirely on the kitchen, even though the customer only sees the dining room.

At a glance

How does the backend work?

The backend has several responsibilities. Each one is a distinct layer of the system, though they all run on the same server.

1. Receiving requests

The backend listens on a network port (typically 80 or 443) for incoming HTTP requests. When a request arrives, the backend routes it — determines which piece of code should handle it based on the URL and HTTP method.

GET  /products          → run the "list products" handler
POST /products          → run the "create product" handler
GET  /products/42       → run the "get product by ID" handler

Think of it like...

A telephone switchboard. The call (request) comes in, and the operator (router) connects it to the right department (handler) based on what the caller asked for.

2. Business logic

Business logic is the set of rules that define how your application works. This is the core of the backend — the part that is unique to your application.

Examples of business logic:

  • A shopping cart must not allow negative quantities
  • A user must verify their email before posting comments
  • A discount applies only if the order total exceeds a threshold
  • Search results are sorted by relevance, then by date

Business logic runs on the server because it must be authoritative. If it ran in the browser, a user could modify it (for example, changing a price to zero). The server is the source of truth.

Think of it like...

The recipes in a kitchen. The recipe says “cook for 20 minutes at 180 degrees.” The chef follows this regardless of what the customer requests. Business logic is non-negotiable — it is the rules the system enforces.

Concept to explore

See business-logic for how business rules are structured and where they live in a codebase.

3. Data access

The backend reads from and writes to the database. It translates application-level requests (“give me all products in the ‘books’ category”) into database queries, and translates the results back into a format the frontend can use.

This layer is often handled by an ORM (Object-Relational Mapper) — a tool that lets you work with database data as programming objects instead of writing raw SQL queries.

Backend requestDatabase query
”Get all books”SELECT * FROM products WHERE category = 'books'
”Create a new user”INSERT INTO users (name, email) VALUES (...)
”Update a price”UPDATE products SET price = 29.99 WHERE id = 42

Concept to explore

See databases for how data is stored, structured, and queried.

4. Authentication and authorisation

Authentication answers: “Who are you?” (login, identity verification). Authorisation answers: “What are you allowed to do?” (permissions, roles).

Both must run on the backend. If the frontend alone decided whether a user was logged in, anyone could edit their browser’s memory and pretend to be an administrator.

Key distinction

Authentication = proving your identity (showing your ID at the door). Authorisation = checking your permissions (the bouncer deciding whether your ID grants you VIP access).

Concept to explore

See authentication for how identity is verified in web applications.

5. Returning responses

After processing, the backend assembles a response: a status code (did it work?), headers (metadata), and a body (the data). For APIs, the body is typically JSON. For web pages, it may be rendered HTML.

The backend decides what to include in the response and what to omit. This is a security boundary — the backend never sends sensitive internal data (database credentials, internal errors, other users’ private information) to the frontend.

Why do we use a backend?

Key reasons

1. Data integrity. The backend is the single source of truth. All data changes go through it, so it can enforce validation rules and prevent corrupted or contradictory data.

2. Security. Sensitive operations — authentication, payment processing, access control — must run in an environment the user cannot tamper with. The server provides that environment.

3. Shared state. When multiple users access the same application, the backend coordinates them. It ensures that when one user updates something, others see the change — without conflicts.

4. Heavy processing. Tasks like searching millions of records, generating reports, or running AI models require more computing power than a browser provides. The backend runs on dedicated hardware optimised for these tasks.

When do we use backend skills?

  • When an application needs to store and retrieve data persistently
  • When business rules must be enforced (validation, access control, workflows)
  • When processing user authentication and authorisation
  • When integrating with external services (payment providers, email services, third-party APIs)
  • When handling computationally expensive tasks (search indexing, data transformation, AI inference)

Rule of thumb

If the operation involves data that must be trusted, shared across users, or protected from tampering, it belongs on the backend.

How can I think about the backend?

The kitchen of a restaurant

The backend is the kitchen in full detail.

  • Receiving orders through the pass = receiving HTTP requests through the API
  • Following recipes = executing business logic
  • Retrieving ingredients from the pantry = querying the database
  • Food safety rules = validation and security (you cannot serve raw chicken regardless of what the customer orders)
  • Plating and sending out dishes = formatting and returning responses
  • The kitchen enforces standards the dining room (frontend) cannot override. A customer can ask for modifications, but the kitchen decides what is actually possible and safe

The back office of a bank

The backend is the back office of a bank.

  • The teller window is the API — where requests come in
  • Verifying your identity = authentication
  • Checking your account permissions = authorisation
  • Processing the transaction = business logic
  • Updating the ledger = writing to the database
  • Handing you a receipt = sending the response
  • The customer never enters the back office. The back office enforces rules (overdraft limits, daily withdrawal caps) that the customer cannot override from the teller window

Concepts to explore next

ConceptWhat it coversStatus
server-side-languagesLanguages used for backend development (Python, Node.js, Go, etc.)stub
business-logicHow application rules are structured and enforcedstub
authenticationHow user identity is verified (sessions, tokens, OAuth)stub
middlewareCode that runs between receiving a request and handling itstub
cachingStoring frequently accessed data for faster responsesstub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Where this concept fits

Position in the knowledge graph 

graph TD
    CSM[Client-Server Model] --> FE[Frontend]
    CSM --> BE[Backend]
    CSM --> API[APIs]
    CSM --> DB[Databases]
    BE --> SL[Server-side Languages]
    BE --> BL[Business Logic]
    BE --> AUTH[Authentication]
    style BE fill:#4a9ede,color:#fff

Related concepts:

  • frontend — the other half of the application; the backend serves data that the frontend displays
  • apis — the contract through which the frontend communicates with the backend
  • databases — where the backend stores and retrieves persistent data
  • separation-of-concerns — the principle that keeps presentation (frontend) and logic (backend) in separate layers

Further reading

Resources

Graph View

Backlinks