> For the complete documentation index, see [llms.txt](https://manual.bubble.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://manual.bubble.io/help-guides/logic/the-frontend-and-backend.md).

# The frontend and backend

Learn what runs on the user's device and what runs on Bubble's server, how the two communicate, and why it matters for speed, security, reliability, and workload.

Everything that happens in your app is the result of two computers working together: the **user's device**, such as their laptop or phone, and **Bubble's server**. In Bubble, we call these the *frontend* and the *backend*. You may also see them called the *client* and the *server*, which mean the same thing.

Understanding which parts of your app run where, and how the two sides talk to each other, makes it much easier to build apps that are fast, secure, and reliable. It's also the foundation for the rest of the [*Logic*](/help-guides/logic.md) section.

<details>

<summary>Why "client" and "server"?</summary>

The terms describe the roles the two computers play. The *server* serves things: it stores your data and sends it out when it's asked for. The *client* is the one asking. In your app, the client is the user's browser or mobile app, and the server is Bubble's infrastructure in the cloud.

</details>

## The frontend

The frontend is **everything that happens on the user's device while they have your app open**. In a web app, that's a page in their browser. In a native mobile app, it's the app installed on their phone.

When a user opens a page, their device downloads what it needs to display it: the page's design, its elements[^1], and the logic you've built. From that point, the frontend runs on the user's device:

<table><thead><tr><th width="235.3125">Part</th><th>What it does on the frontend</th></tr></thead><tbody><tr><td><a href="/help-guides/design/elements.md">Elements</a></td><td>Text, images, inputs, buttons, and lists are drawn on the user's screen. Some show static content, while others display data requested from the server, such as the user's name or a list of tasks.</td></tr><tr><td><a href="/help-guides/logic/workflows.md">Frontend workflows</a></td><td>React to what the user does, such as clicking a button or changing an input. Some finish their work right on the device, and others send requests to the server.</td></tr><tr><td><a href="/help-guides/data/temporary-data/custom-states.md">Custom states</a></td><td>Store temporary values in the device's memory, which disappear when the page is closed or reloaded.</td></tr><tr><td><a href="/help-guides/data/static-data/option-sets.md">Option sets</a> and <a href="/help-guides/data/static-data/app-texts-translations.md">app texts</a></td><td>Are downloaded with your app, so they're available instantly without asking the <a data-footnote-ref href="#user-content-fn-2">database</a>.</td></tr></tbody></table>

You build the frontend in the **Design** and **Workflow** tabs.

{% hint style="info" %}
The frontend is like a temporary universe that only exists while the user has your app open. When they close the page, any frontend workflow that hasn't finished stops, and nothing more happens on their device.
{% endhint %}

***

## The backend

The backend is everything that runs on Bubble's server. Users don't see it directly, and it doesn't depend on anyone having your app open. If your project has both a web app and a native mobile app, they share the same backend.

<table><thead><tr><th width="198.93359375">Part</th><th>What it does on the backend</th></tr></thead><tbody><tr><td><a href="/help-guides/data/the-database.md">The database</a></td><td>Stores all your app's data, such as users, posts, and orders.</td></tr><tr><td><a href="/help-guides/data/the-database/protecting-data-with-privacy-rules.md">Privacy rules</a></td><td>Decide which data each user is allowed to see, before anything is sent to their device.</td></tr><tr><td><a href="#backend-workflows">Backend workflows</a></td><td>Run on the server, on a schedule, in response to changes in the database, or when another app sends a request.</td></tr><tr><td><a href="/help-guides/integrations/api/the-bubble-api.md">The Bubble API</a></td><td>Lets other apps and services read and change data in your app, or trigger workflows in it.</td></tr><tr><td><a href="/help-guides/integrations/api/the-api-connector.md">The API Connector</a></td><td>Sends requests to external services. By default, calls are routed through Bubble's server, even when a frontend workflow starts them, which keeps API keys and other sensitive values off the user's device. Certain calls can be set up to run directly from the browser.</td></tr></tbody></table>

You build backend workflows in the **Backend workflows** tab.

***

## How the two sides communicate

Most of what users do in your app involves a round trip between the frontend and the backend. Here's what happens when a user saves a new task:

1. The user types a task name and clicks **Save**. This happens on the frontend.
2. A frontend workflow starts and sends a request to Bubble's server, along with the task name.
3. The server checks the request, saves the task to the database, and sends a response back.
4. The frontend receives the response, and the new task appears in the user's list.

Each round trip takes a moment, depending on the user's connection and how much work the server has to do. That's why some actions in your app feel instant, and others take a short while.

Not everything needs the server, though. Some actions run entirely on the user's device:

| Runs on the device only                     | Needs the server                                     |
| ------------------------------------------- | ---------------------------------------------------- |
| Showing, hiding, or animating elements      | Creating, changing, or deleting data in the database |
| Setting a custom state                      | Searching the database                               |
| Scrolling to an element or resetting inputs | Sending emails                                       |
| Navigating between groups on the same page  | Calling an external API through the API Connector    |
| Reading option sets and app texts           | Signing users up and logging them in                 |

{% hint style="info" %}
An action that runs on the device can still need the server if it depends on data that hasn't loaded yet. For example, showing a hidden [repeating group](#user-content-fn-3)[^3] can make it fetch its data from the database. A single workflow can also mix the two, with some actions running on the device and others on the server.

**Article:** [Client-side and server-side processing](/help-guides/workload/understanding-workload/client-side-and-server-side-processing.md)
{% endhint %}

***

## Why the difference matters

### Speed

Actions that run only on the user's device happen instantly, while actions that need the server have to wait for a round trip. If something in your app feels slow, it's often because it's waiting on the server, for example a search that loads a lot of data.

### Security

Anything that reaches the user's device can be seen by the user, even if it's not shown on the page. A tech-savvy user can open their browser's developer tools and look at the data your app has downloaded. When Bubble loads a thing, it downloads every field your privacy rules allow the user to see, not just the ones you show on the page.

That's why the backend is where your app's security lives. [Privacy rules](/help-guides/data/the-database/protecting-data-with-privacy-rules.md) run on the server, so data a user isn't allowed to see doesn't leave it. Hiding an element on the page or filtering a list on the frontend doesn't protect data, because by then it's already on the user's device.

The same goes for logic. Conditions checked on the user's device can be tampered with, so base sensitive conditions on something the server can check, such as a field in the database.

{% hint style="warning" %}
Don't rely on the frontend to keep data private. If a user shouldn't see something, protect it with privacy rules, so it stays on the server.
{% endhint %}

The [security dashboard](#user-content-fn-4)[^4] can help you spot potential vulnerabilities, such as missing privacy rules.

**Article:** [Protecting data with privacy rules](/help-guides/data/the-database/protecting-data-with-privacy-rules.md)\
**Article:** [Client-side and server-side](/help-guides/security/client-side-and-server-side.md)\
**Article section:** [Using conditions for security](/help-guides/logic/conditions.md#using-conditions-for-security)

### Reliability

Frontend workflows depend on the user keeping your app open. If they close the page halfway through a long workflow, the rest of it doesn't run. Backend workflows keep running on the server no matter what the user does, which makes them a better fit for work that has to finish, such as processing a payment.

### Workload

Work done on Bubble's server uses [*workload*](/help-guides/workload.md), the measure of how much server work your app does. Actions that run only on the user's device, like showing an element or setting a custom state, don't add to it.

**Article series:** [Optimizing workload](/help-guides/workload/optimizing-workload.md)

***

## Backend workflows

Backend workflows run entirely on Bubble's server. They can start without any action from the user, and they keep running even if the user closes your app. That makes them useful for a different kind of work than frontend workflows, which mostly react to what the user does on the page.

With backend workflows, you can:

<table><thead><tr><th width="309.390625">Use</th><th>Example</th></tr></thead><tbody><tr><td><a href="/help-guides/integrations/api/the-bubble-api/the-workflow-api/api-workflows/scheduling-api-workflows.md">Schedule a workflow</a></td><td>Send an onboarding email two days after a user signs up, or end a trial after 30 days.</td></tr><tr><td><a href="/help-guides/logic/workflows/events/backend-events.md#running-a-workflow-at-an-interval">Run a workflow on a schedule</a></td><td>Generate a weekly report or process a monthly subscription payment.</td></tr><tr><td><a href="/help-guides/logic/workflows/events/backend-events/database-trigger-events.md">React to changes in the database</a></td><td>Notify a store owner whenever a new order is created.</td></tr><tr><td><a href="/help-guides/integrations/api/the-bubble-api/the-workflow-api.md">Accept requests from other apps</a></td><td>Let an external service, like a payment provider, trigger a workflow through an <a data-footnote-ref href="#user-content-fn-5">API request</a>.</td></tr></tbody></table>

Frontend and backend workflows often work together. For example, a frontend workflow can use the **Schedule API workflow** action to schedule a backend workflow, so the user can click a button and move on while the server finishes the work.

**Article series:** [Backend events](/help-guides/logic/workflows/events/backend-events.md)

### Enabling backend workflows

Backend workflows are turned off by default. The first time you use them in an app, you need to turn them on in your app's settings.

{% stepper %}
{% step %}

#### Open the API settings

Go to the **Settings** tab and open the **API** section.
{% endstep %}

{% step %}

#### Turn on backend workflows

Check *Enable Workflow API and backend workflows*.

<figure><img src="https://34394582-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M5sbzwG7CljeZdkntrL%2Fuploads%2FKLvi8GKN88j20iWoANd2%2Fenabling-bubble-api.png?alt=media&amp;token=c75482f9-6450-4f18-b8b9-9576abea1e4b" alt="The APIs and Backend Workflows settings, with the Enable Workflow API and backend workflows checkbox checked."><figcaption><p>Backend workflows are turned off by default, but you can turn them on in the API section of the Settings tab.</p></figcaption></figure>
{% endstep %}

{% step %}

#### Open the Backend workflows tab

Go to the **Backend workflows** tab to start building.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
You can use backend workflows on the Free plan, but some operations, such as API calls and emails, have limits meant for testing.

**Article:** [API](/help-guides/integrations/api.md)
{% endhint %}

***

## Build frontend and backend workflows with Bubble AI

The [Bubble AI Agent](/help-guides/ai/bubble-ai-agent.md) can build on both sides of your app. It can create and edit frontend and backend workflows, and it can connect the two by adding the **Schedule API workflow** action to a frontend workflow. You can also ask it to explain how your app is set up. Depending on the approval mode you've picked, the Agent can show you a plan to approve or cancel before it changes anything, and you can review the result in the **Workflow** and **Backend workflows** tabs.

The Agent declines very complex workflows, and it can't build custom events, payment actions, or analytics actions in backend workflows. It also can't run or test a workflow for you, but it can explain how to set up things it can't build.

Here are a few prompts to try:

{% code overflow="wrap" %}

```
What's the difference between frontend and backend workflows?
```

{% endcode %}

{% code overflow="wrap" %}

```
Which actions in this workflow run on the user's device, and which need the server?
```

{% endcode %}

{% code overflow="wrap" %}

```
Create a backend workflow named end-trial with a parameter for user. It should change the user's Trial active field to no.
```

{% endcode %}

{% code overflow="wrap" %}

```
Connect the end-trial backend workflow to the Start trial button on my signup page, and schedule it to run 30 days from now.
```

{% endcode %}

```
How do privacy rules work in my app?
```

**Article:** [Edit apps with AI](/help-guides/ai/bubble-ai-agent/edit-apps-with-ai.md)

***

## FAQ: The frontend and backend

<details>

<summary>What's the difference between the frontend and the backend?</summary>

The frontend is everything that runs on the user's device while they have your app open, like the page, its elements, and frontend workflows. The backend is everything that runs on Bubble's server, like the database, privacy rules, and backend workflows.

</details>

<details>

<summary>Is "client-side" the same as "frontend"?</summary>

Yes. Client-side and frontend both mean the user's device, and server-side and backend both mean Bubble's server.

</details>

<details>

<summary>What happens if a user closes the page while a workflow is running?</summary>

A frontend workflow stops, and any actions that haven't run yet won't run. Backend workflows keep running on the server whether the user has your app open or not.

</details>

<details>

<summary>Is data on the frontend secure?</summary>

It's protected from third parties, since data is encrypted on its way to the user's device. It isn't protected from the user, though: anything that reaches their device can be inspected, even if it's hidden on the page. To keep data private, use [privacy rules](/help-guides/data/the-database/protecting-data-with-privacy-rules.md), which run on the server and stop the data from being sent in the first place.

</details>

<details>

<summary>When should I use a backend workflow instead of a frontend workflow?</summary>

Use a backend workflow when the work needs to happen without the user, such as on a schedule or in response to a change in the database, or when it has to finish even if the user leaves. You can also use backend workflows to override privacy rules, or for sensitive workflows that shouldn't be part of your app's frontend code.

Use a frontend workflow when you're reacting to what the user does on the page.

</details>

<details>

<summary>Do API Connector calls run on the frontend or the backend?</summary>

By default, they're routed through Bubble's server, even when a frontend workflow starts them. That keeps API keys and other sensitive values off the user's device. Certain calls can be set up to run directly from the browser.

**Article:** [The API Connector](/help-guides/integrations/api/the-api-connector.md)

</details>

<details>

<summary>Do frontend workflows use workload?</summary>

It depends on what they do. Actions that run only on the user's device, like showing an element, don't use workload. Actions that need the server, like creating a thing, do, whether a frontend or a backend workflow runs them.

**Article:** [Client-side and server-side processing](/help-guides/workload/understanding-workload/client-side-and-server-side-processing.md)

</details>

<details>

<summary>Do native mobile apps have a frontend and a backend too?</summary>

Yes. In a native mobile app, the frontend is the app installed on the user's device, and the backend is Bubble's server. If your project has both a web app and a native mobile app, they share the same backend.

</details>

[^1]: *Elements* are the objects that you place on the page as you design your app. There are many different types of elements, like texts, buttons, input fields, and calendars.\
    **Article series:** [Elements](/help-guides/design/elements.md)

[^2]: The database stores all your app's data, such as users, posts, and orders.\
    **Article:** [The database](/help-guides/data/the-database.md)

[^3]: A *repeating group* is a container element used to display a list of things. For example, you can use it to show a list of users, products, or blog posts.\
    **Article:** [Repeating groups](/help-guides/design/elements/web-app/containers/repeating-groups.md)

[^4]: The security dashboard is Bubble's security reporting and monitoring tool, designed to help you identify potential vulnerabilities in your app.\
    **Article series:** [Security dashboard](/help-guides/security/security-dashboard.md)

[^5]: An API request is a message sent to your app to ask for specific information or perform a specific task.\
    **Article series:** [API](/help-guides/integrations/api.md)