What is a backend? The server side of an application, explained

A backend is a server-side system: the code, database, and infrastructure that handle an app’s requests and store its data behind the UI. Every piece of software with users has two halves. The half they see and touch — screens, buttons, forms — is the frontend.

The half they never see, the one that decides what the buttons are allowed to do and remembers what happened after the app is closed, is the backend. The old mechanic’s analogy still holds: the driver works the dashboard, the mechanic works the engine.

This entry is about the engine.

Key takeaways

One request, end to end

The clearest way to see a backend is to watch one request cross it. A user taps “show my open tasks”; this is what happens on the other side of the API:

GET /classes/Todo?where={"done":false} HTTP/1.1    ← the frontend asks
Authorization: Bearer eyJhbGci…                     ← who is asking

  backend ─┬─ API layer        parse the request, check the token
           ├─ authorization    may this user read these rows?
           ├─ business logic   apply the rules (only the caller's tasks)
           ├─ data layer       query the database, shape the result
           └─ response         200 OK + JSON, in under 100 ms

{ "results": [ { "objectId": "xKd91m", "title": "Ship the release", "done": false } ] }

The same conversation from the frontend’s side, through an SDK that turns it into one line per platform:

// JavaScript / Node.js — Back4app JS SDK
// The frontend asks the backend a question; the backend answers from the database
const query = new Parse.Query('Todo');
query.equalTo('done', false);
const open = await query.find();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
console.log(`${open.length} open todos`);

// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false);
final response = await query.query();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
print('${response.results?.length ?? 0} open todos');

// iOS / Swift — Back4app Swift SDK
// The frontend asks the backend a question; the backend answers from the database
let query = Todo.query("done" == false)
query.find { result in
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if case .success(let open) = result { print("\(open.count) open todos") }
}

// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.findInBackground { open, e ->
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if (e == null) println("${open.size} open todos")
}

Frontend vs. backend

The distinction people search for most, in one table:

That last row is the one that matters for security: anything in the frontend can be read and modified by the user. That is why validation, permissions, and secrets belong in the backend, and why every API call is treated as untrusted until the server has checked it.

Client side and server side

The two terms are not two kinds of backend; they are the two ends of every request. The client side is whatever code runs on the user’s device — rendering the interface, holding temporary state, sending requests.

The server side is whatever code runs on machines the user cannot reach — receiving those requests, running the real logic, reading and writing the database, and answering. “Backend” and “server side” are used interchangeably for that second half, and this entry does the same.

What a backend is made of

The classic framing calls the frontend the presentation layer and the backend the data access layer, and describes the backend as three things working together: the hardware resources, the software running on them, and the network infrastructure between them and the user.

That is still true, but it is more useful to read a backend as a stack of responsibilities, most of which exist in every product regardless of size:

• API layer — the public contract: REST or GraphQL endpoints that the frontend and other systems call.
• Business logic — the rules that make the product the product: what a valid order is, who may approve what, how a score is computed.
• Data layer — the database and the code that models, queries, and migrates it.
• Authentication and authorization — who the caller is and what they may do, enforced on every request.
• Background work — jobs and schedules for everything that should not block a request: emails, reports, syncs, cleanups.
• Infrastructure — the servers, containers, or functions it all runs on, plus deployment, logging, monitoring, backups, and scaling.

The first five are product work. The sixth is operations, and it is the part that modern hosting models exist to remove.

Backend architectures

The original version of this topic described three families — serverless, server-oriented, and decentralized — and the taxonomy still holds. What changed is the default: in 2026 the serverless family is where most new products start, and “server-oriented” increasingly means containers rather than machines.

Server-based backends. Your team provisions machines, virtual machines, or containers, installs a runtime and a database, and operates them. Maximum control, maximum responsibility: capacity, patching, availability, and the on-call rotation are yours.

The classic arguments for it still apply — one place that shares data between several applications, straightforward integrations, a single access point to secure — and the shape inside can be a monolith or microservices; the operating model is the same.

Serverless backends. A provider runs the infrastructure and bills per use. Two flavors: Function as a Service, where you deploy custom code as functions that scale from zero, and Backend as a Service, where the database, auth, APIs, storage, and functions arrive as a managed platform.

The win is speed — no servers to build before the first feature — and the trade is control over the lowest layers. The full ladder of hosting models is compared in IaaS vs. PaaS vs. BaaS vs. FaaS.

Decentralized backends. No single operator; state lives on a peer-to-peer network, usually open-source, as in blockchains and content-addressed storage. Bitcoin and Ethereum are the canonical examples, and the frontend of such an app is often hosted the same way, on networks like IPFS or Swarm rather than on a server.

Censorship resistance and no central point of control, at the cost of latency, throughput, and a very different programming model. A niche with real uses, not a general-purpose replacement for the other two.

Server-based vs. serverless vs. BaaS vs. decentralized

Common use cases

• Mobile and web apps — accounts, data that outlives the session, and sync across devices all need a server side.
• Multi-user products — anything where one user’s action must be seen by another: collaboration, marketplaces, chat.
• Payments and sensitive operations — secrets and money never belong on the device; the backend holds the keys and talks to the providers.
• Integrations and automation — webhooks, scheduled jobs, and pipelines that run whether or not any user is online.
• AI features — model calls, retrieval, and tool execution run server-side, where keys stay private and results can be cached and audited.

Which backend approach should you choose? A decision matrix

Limitations and trade-offs

• The backend is where mistakes become everyone’s problem. A frontend bug breaks a screen; a backend bug corrupts data or exposes it. Validation, permissions, and tests carry more weight here than anywhere else in the codebase.
• Operations never disappear — they move. Managed platforms absorb servers, scaling, and backups, but someone still owns the data model, the access rules, and the budget. Choose a model for the responsibilities you want to keep, not the ones you want to forget.
• Control and speed pull in opposite directions. The more of the stack you run yourself, the more you can customize and the longer everything takes; the less you run, the faster you ship and the more you depend on a provider’s roadmap and pricing.
• The network is part of the contract. Every frontend-to-backend call can be slow, fail halfway, or arrive twice; latency budgets, retries, and idempotency are backend concerns from the first endpoint.
• “Serverless” still has servers. Cold starts, execution limits, and per-use billing are real constraints; they are simply someone else’s machines with a different cost curve.

The backend on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions.

Mapped onto the layers above: the data layer and the API layer are generated from your data model, authentication and class-level permissions enforce who may do what on every request, Cloud Code holds the business logic and background jobs that are specific to your product, and the infrastructure layer — hosting, scaling, backups, monitoring — is the platform’s job.

The request dissected at the top of this page is real Back4app wire format, and the SDKs that sent it are how the frontend talks to that backend from every major platform.