Frontend, Backend, and Database: How They Work Together

The short answer

The frontend presents an interface and collects user input. The backend receives requests, validates input, applies business rules, and decides what response to return. A database stores and retrieves data under controlled access.

For a common data-backed action, the flow looks like this:

Why software is separated into responsibilities

An interface, a pricing rule, and a durable customer record change for different reasons. Keeping their responsibilities distinct makes it easier to change one without rewriting everything else. It also creates security boundaries: code running in a visitor’s browser should not automatically receive the same credentials and privileges as trusted application code.

The separation is logical. A small application might serve frontend files, run backend logic, and host a database on one computer. A larger system might place them across many processes and regions. “Three layers” describes who is responsible for what; it does not tell you how many machines exist.

What the frontend does

The frontend is the part a user directly interacts with. On the web, that usually means HTML for structure, CSS for presentation, and JavaScript for behavior in the browser.

A frontend can:

• display content and controls;
• collect and validate input for a better user experience;
• update local interface state;
• send requests and interpret responses;
• render loading, success, empty, and error states.

Not every frontend action needs a backend. Opening a menu, filtering data already loaded into memory, or calculating a preview can happen locally. But browser code is controlled by the user’s environment and can be inspected or modified. Frontend validation therefore improves usability; it cannot replace server-side validation for a protected operation.

The browser’s request-and-response machinery is standardized through the web platform’s Fetch model.The WHATWG Fetch Standard defines the core Request and Response concepts used by browser fetching.² Frameworks add useful conventions, but they do not remove the network boundary.

What the backend does

The backend is trusted application logic that runs outside the user’s browser. It commonly receives a request, parses its input, identifies the caller, checks permission, applies business rules, talks to dependencies, and creates a response.

Suppose a user asks to buy the last item in stock. The frontend can show a button and an estimated total, but the backend must make the authoritative decision. It needs current inventory, current pricing rules, and the user’s permission to place the order. A modified frontend must not be able to bypass those checks.

The backend does not always query a database. It might return a computed value, serve a cached result, publish work to a queue, call a payment provider, or reject invalid input before any dependency is contacted. “Backend” names the application responsibility, not one particular technology or storage system.

How a Backend Processes a Request follows these responsibilities through an application in more detail.

What the database does

A database organizes data and provides operations to read or change it. Depending on the database, it may also enforce constraints, coordinate concurrent changes, persist data to storage, maintain indexes, and control which database clients can perform which operations.

The database is not simply “the backend.” Backend code decides application behavior; the database manages data according to database rules and commands. PostgreSQL, for example, describes its own client/server architecture: application clients connect to a database server process that manages database files and operations.PostgreSQL’s architecture guide separates database clients from the database server.³

In a typical public web application, the browser should not receive private database credentials or unrestricted network access to the database. The backend acts as the controlled boundary. OWASP recommends limiting which hosts can reach a database and granting narrowly scoped privileges.The OWASP database guidance covers isolation, allowed hosts, credentials, and least privilege.⁴

Some platforms expose a purpose-built data API to browsers or mobile apps. That can be safe when authentication, authorization, validation, and database policies are deliberately enforced. It is not the same as exposing an unrestricted private database connection.

How Databases Store and Retrieve Data opens this boundary to examine models, queries, indexes, and transactions.

How the three work together

Consider a user changing their display name:

1. The frontend collects the proposed name.
2. It sends a request to an application endpoint.
3. The backend validates the format, identifies the user, and checks whether that user may edit the profile.
4. If needed, the backend tells the database to update the correct record.
5. The database accepts or rejects the operation and returns a result.
6. The backend turns that result into an HTTP response.
7. The frontend uses the response to update the screen or explain the error.

Each arrow can fail independently. That is why “the app is broken” is rarely a useful diagnosis.

Example: signing into an application

A sign-in form illustrates the difference between authentication and interface behavior.

The frontend collects an identifier and secret, then sends them over a protected connection. The backend validates the request and uses the application’s authentication process to verify the claimed identity. Depending on the design, it may consult a user store or an external identity provider. If successful, it establishes some form of authenticated session or returns credentials the client can use on later requests.OWASP’s authentication guidance explains identity verification and session-management concerns.⁵

The frontend can detect an empty field before sending, but it cannot authoritatively decide that the supplied credentials are valid. The backend owns that decision because the browser cannot be trusted with password-verification secrets or unrestricted user records.

Example: loading a product page

For a product page, the frontend might request /api/products/42. The backend parses 42, applies visibility and pricing rules, and asks a database or cache for product data. It then returns a representation—often JSON for a client-rendered interface or HTML for a server-rendered page.

Several valid variations exist:

• A static product page might be served without running backend logic for that request.
• A cached response might avoid a database read.
• Server-rendered code might produce the HTML before the browser receives it.
• One backend request might combine inventory, pricing, and recommendations from separate services.

The responsibility model still helps even when the topology changes: presentation, application decisions, and durable data remain different concerns.

Where APIs fit

An API is an interface through which software components communicate. In this path, the frontend commonly calls a backend API using HTTP. The API defines which operations are available and how requests and responses are represented.

An API is not automatically “the backend.” It is a boundary exposed by a backend or another service. A backend can also call payment, mapping, or email APIs. The same application may expose one API to its frontend and use several others internally.

MDN’s client-server overview shows the browser and server exchanging HTTP requests and responses while server-side code may retrieve data and generate a response.See the client-server request flow in MDN’s server-side introduction.¹

APIs and JSON separates the interface contract, HTTP exchange, and data representation.

Where authentication and authorization fit

Authentication establishes who a caller is. Authorization decides what that caller is allowed to do. They often happen in backend request handling, but they are separate decisions.

A frontend may hide an admin button from an ordinary user, but the backend must still reject an unauthorized request sent manually. OWASP recommends checking permission on every protected request rather than relying on interface visibility.OWASP’s authorization guidance distinguishes access decisions from authentication and emphasizes per-request checks.⁶

The database can add another layer of access control through database users, grants, and row-level policies. Those controls support the application boundary; they do not remove the need for correct application authorization.

Authentication and Sessions follows this boundary across login, later requests, permission checks, and logout.

Common architectural variations

The labels remain useful across different deployments:

• Server-rendered application: backend code produces HTML, so some presentation work happens before the response reaches the browser.
• Client-rendered application: the browser receives application JavaScript and later asks APIs for data.
• Backend for frontend: separate backend endpoints are shaped for web, mobile, or other clients.
• Serverless functions: application handlers run on managed infrastructure, often as separate invocations.
• Direct data API: a managed service exposes a restricted API backed by database policies.
• Multiple data systems: one backend can use a relational database, cache, search index, object storage, and queue.

None of these variations turns the three labels into physical-machine names. One process can own several responsibilities, and one responsibility can be distributed across many processes.

Common misconceptions

Debugging scenario

Knowledge check

What to learn next