---
term: 'Backend (Server Side)'
seoTitle: 'What is a Backend? Meaning, Frontend vs. Backend, Architectures'
headline: 'What is a backend? The server side of an application, explained'
slug: backend-meaning
category: backend-compute
shortDefinition: '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.'
relatedTerms:
- baas-vs-custom-backend
- api
- serverless-architecture
- backend-sdk
- decoupled-architecture
- scaling-application-backends
contrastsWith:
- decoupled-architecture
faq:
- question: 'What does backend mean?'
answer: 'The part of an application users never see: the server-side code, the database, and the infrastructure that receive requests from the interface, apply the business rules, read and write data, and send back a response. If the frontend is the dashboard of a car, the backend is the engine and the fuel system — invisible from the seat, responsible for everything that moves.'
- question: 'What is a frontend?'
answer: 'The part of an application users can see and interact with: the screens, buttons, forms, and navigation rendered on their device by a browser or a mobile app. It is the presentation layer. It captures input and shows results, but the decisions and the data behind those results live in the backend, which the frontend reaches through an API.'
- question: 'What is the difference between frontend and backend?'
answer: 'Where the code runs and who it talks to. The frontend runs on the user''s device — browser or app — and renders screens, captures input, and calls APIs. The backend runs on servers you (or a platform) control and owns the data, the rules, and the security. The two meet at an API: the frontend asks, the backend decides and answers.'
- question: 'Is the backend the same as the server?'
answer: 'Not quite. A server is a machine or process that answers network requests; the backend is the whole system behind the interface — application code, database, authentication, background jobs, and the servers they run on. One backend may span many servers, and in serverless architectures the "server" is rented by the millisecond and never managed directly.'
- question: 'What are the types of backend?'
answer: 'Grouped by who runs the servers: server-based backends, where your team provisions and operates machines or containers; serverless backends, where a provider runs the infrastructure and bills per use — Function as a Service for custom code and Backend as a Service for the whole stack; and decentralized backends, where no single party operates the system and peers share state over a network. Most products today combine the first two.'
- question: 'Is a database a backend?'
answer: 'No — it is one component of a backend, usually the most important one. A database stores and retrieves data; the backend wraps it with an API, validation, permissions, and logic so clients never touch it directly. A platform that exposes a database through generated APIs with auth and access rules is a backend; a bare database is not.'
- question: 'What is Backend as a Service (BaaS)?'
answer: 'A managed backend you configure instead of build: a hosted database, auto-generated REST and GraphQL APIs, user authentication, file storage, push notifications, and serverless functions for custom logic. You keep writing the frontend and the rules that matter to your product; the platform runs the rest. It is the fastest way to get a production backend for a mobile or web app.'
- question: 'Which languages are used for backend development?'
answer: 'Any language with a mature server ecosystem: JavaScript and TypeScript on Node.js, Python, Java and Kotlin, C#, Go, Ruby, PHP, and Rust are the common choices. The language matters less than the surrounding pieces — the framework, the database driver, the hosting model — and in a BaaS most backend work happens through the platform''s SDKs and a small amount of serverless code.'
- question: 'What does a backend developer do?'
answer: 'Designs the data model, builds and documents the APIs, implements business logic and background jobs, secures authentication and permissions, and keeps the system fast and available as traffic grows. In practice a large share of the job is operations — deployments, monitoring, scaling, backups — which is exactly the share that managed platforms absorb.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'Introduction to the server side — MDN Web Docs'
url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction'
- name: 'Client-Server overview — MDN Web Docs'
url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview'
- name: 'RFC 9110 — HTTP Semantics'
url: 'https://www.rfc-editor.org/rfc/rfc9110'
- name: 'The Twelve-Factor App'
url: 'https://12factor.net/'
- name: 'Frontend and backend — Wikipedia'
url: 'https://en.wikipedia.org/wiki/Frontend_and_backend'
cta:
title: 'A production backend, without building one'
text: 'Back4app gives your app a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code functions from day one — the whole server side, configured instead of built.'
linkText: 'Start building free'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-19'
translationKey: backend-meaning
---
**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
| Question | Answer |
| --- | --- |
| The definition | Everything behind the interface: server code, database, auth, jobs, infrastructure |
| The boundary | An API — the frontend asks, the backend validates, decides, and answers |
| The layers | API · business logic · data · authentication · background work · infrastructure |
| The hosting models | Server-based · serverless (FaaS and BaaS) · decentralized |
| The 2026 default | Rent the generic parts (database, auth, APIs); write only the logic that is yours |
## 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:
```text
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:**
```javascript
// 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
// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder(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');
```
**Swift:**
```swift
// 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") }
}
```
**Kotlin:**
```kotlin
// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery("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:
| | Frontend | Backend |
| --- | --- | --- |
| Where it runs | The user's device: browser, mobile app, desktop | Servers you or a provider control |
| What it owns | Layout, interaction, local state, accessibility | Data, business rules, identity, security |
| How it fails | A broken screen for one user | Wrong data or downtime for every user |
| Typical languages | JavaScript/TypeScript, Swift, Kotlin, Dart | JavaScript/TypeScript, Python, Java, Go, C#, Ruby, PHP, Rust |
| What "done" means | It looks and feels right | It is correct, secure, and still fast under load |
| Who sees the code | Anyone — it ships to the device | Only your team — it never leaves the server |
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](/glossary/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.
```mermaid
flowchart LR
accTitle: Frontend, backend, and the API between them
accDescr: A frontend on the user's device sends requests through an API to the backend, which contains business logic, authentication, and background jobs, and talks to a database and external services before returning a response.
F["Frontend
(browser, mobile app)"] -->|"request over the API"| B["Backend
logic · auth · jobs"]
B --> D[("Database")]
B --> S["External services
(payments, email, AI)"]
B -->|"response"| F
```
## 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](/glossary/rest-api/) 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](/glossary/nosql-vs-sql/) and the code that models, queries, and migrates it.
- **Authentication and authorization** — [who the caller is and what they may do](/glossary/authentication-vs-authorization/), enforced on every request.
- **Background work** — [jobs and schedules](/glossary/background-jobs-task-schedulers/) 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](/glossary/scaling-application-backends/).
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](/glossary/microservices-vs-monolith/); the operating model is the same.
**Serverless backends.** A provider runs the infrastructure and bills per use. Two flavors: [Function as a Service](/glossary/serverless-architecture/), 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](/glossary/iaas-paas-baas-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
| Model | Who runs the servers | You write | Scales by | Best for |
| --- | --- | --- | --- | --- |
| Server-based | Your team | Everything: app, data layer, ops | Adding capacity you manage | Unusual requirements, full control, existing ops teams |
| Serverless (FaaS) | The provider | Functions and the data layer | Per invocation, from zero | Event-driven logic, spiky traffic, small teams |
| BaaS | The provider | Frontend + custom logic only | Per use, platform-managed | Mobile and web apps that need auth, data, and APIs fast |
| Decentralized | A peer network | Smart contracts, clients | Network growth | Trust-minimized systems, shared public state |
## 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
| Your situation | Reach for |
| --- | --- |
| A new mobile or web product that needs auth, data, and APIs this week | BaaS — configure the generic 80 %, write the 20 % that is yours |
| Event-driven logic with bursty traffic and no stable baseline | Serverless functions |
| Strict requirements the managed platforms cannot express | Server-based, with containers and a real ops plan |
| A system whose whole point is that no one operates it | Decentralized |
| An existing server-based backend that is slow to change | Move the generic parts to a [managed backend](/glossary/baas-vs-custom-backend/) first, keep the custom core |
## 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](/glossary/cloud-vendor-lock-in/).
- **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](/glossary/class-level-permissions-clp/) enforce who may do what on every request, [Cloud Code](/glossary/cloud-code-serverless-functions/) 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](/glossary/backend-sdk/) that sent it are how the frontend talks to that backend from every major platform.