In the Infrastructure section of the manual, we explain the differences between client-side and server-side processes. Running a Bubble app is a collaborative effort between the user's device (computer, tablet, or phone) and the Bubble server. Although more than one server can be involved, this article focuses on these two devices and how they affect workload management.
Workload is essentially the aggregated metric indicating how much work the server does to keep your app running. While server-side operations contribute to this workload, client-side workflows, such as animating an element, do not add to the server’s workload.
Still, essential client-side operations can sometimes depend on the server to function properly. For example, loading a page requires the server to compile and send data to the user’s device, even if the page rendering happens client-side. Likewise, animating an element is a client-side action, but a condition or other actions within the same workflow may still require server communication, and showing a previously hidden repeating group can lead to its data source fetching data from the database.
In this article, we'll explore which workflows are performed server-side and client-side, and the design decisions that can force Bubble to include server-side operations, even in workflows that are typically client-side.
The difference between client-side and server-side operations
While it may not cover every scenario, asking the following overarching questions can often reveal whether an operation involves the server:
Question | Performed | Reason |
Does the operation require accessing or modifying data stored in the database? | Server-side | Involves database operations |
Is the operation using or calling an API? | Server-side | APIs are routed through the server |
Is the operation related to user authentication or session management? | Server-side | Involves security and session verification |
Does the operation involve complex calculations or data processing? | Server-side | Leverages server resources for processing |
Is the operation dependent on real-time user interactions, like displaying or hiding elements? | Client-side | Handled by the user’s device |
Going more into detail, we can also divide typical processes into client-side and server-side. The list below is not comprehensive, but illustrates some typical operations that would include either the client or the server. In principle, all operations that involve the database, files, backend workflows and external APIs will need to involve the Bubble server in some way.
Typical Client-side Operations | Typical Server-side Operations |
Set a custom state value | User authentication (login/signup) |
Element visibility (show/hide) | Database searches and queries |
Form input handling | Sending emails (confirmation, reset) |
Animations and transitions | Data creation, modification, and deletion |
Scrolling to elements | External API calls |
Client-side calculations | File uploads and deletions |
Displaying data | Scheduled workflows |
Updating element states | Managing user sessions |
Resetting input fields | Assigning temporary passwords |
Showing alerts and messages | Processing recurring events |
It's important to understand that even if an operation can be done client-side, its settings and properties might still require server involvement.
For example, the "Display data" action is technically client-side, but if you're displaying data from the database in a container element like a group, that data must be loaded from the server. Conversely, if you use "Display data" to load a static number, it can be handled entirely client-side.
Additionally, the purpose of this guide is to help you understand how workload calculation is affected by client-side and server-side operations—not to suggest that you should always avoid server operations. All Bubble apps need to connect to the server to function, and there are security, efficiency, and functionality considerations when trying to move tasks away from the server.
Below, we’ll start breaking down how workflows and elements involve the server when needed.
Workflows
A workflow can consist of many pieces. To understand what happens where, we need to divide the workflow into separate categories that can potentially spend workload. All backend workflows are performed server-side, but frontend workflows can be executed server-side or client-side.
A workflow consists of components like the below tree:
The event
Actions
Dynamic expressions:
Conditions on the workflow
Conditions on separate actions
Dynamic expressions that are part of an action
Let's go over each component in more detail.
Events
Every workflow in Bubble is triggered by an event, such as a button being clicked. When Bubble identifies an event happening, it will check any additional conditions on the event, and proceed to run the actions inside.
Events table
Event | Performed | Reason |
User is logged in | Server-side | Authentication is managed on the server |
User is logged out | Server-side | Session management is handled on the server |
Page is loaded | Both | The page is loaded event can be triggered before the page loads, but can also be triggered on the client, depending on actions and conditions |
Do every 5 seconds | Client-side | Timer events are handled client-side |
Do when condition is true | Depends | It depends on the dynamic expression |
An unhandled error occurs | Client-side | Errors are detected and managed locally. An error can be the result of a server-side action. |
An element is clicked | Client-side | Click events are handled client-side |
An input's value is changed | Client-side | Input changes are managed client-side |
An element has an error running a workflow | Client-side | Element errors are detected locally. An error can be the result of a server-side action. |
Custom event (on page) | Client-side | Custom events on the page are handled locally. Actions and dynamic expressions can still be processed server-side. |
Custom event (Backend) | Server-side | Backend events are always processed server-side. |
API workflow | Server-side | Backend events are always processed server-side. |
Recurring workflow | Server-side | Backend events are always processed server-side. |
Database trigger event | Server-side | Backend events are always processed server-side. |
Actions
Inside each workflow, there are one or more actions. When an event is triggered, Bubble checks the conditions for each action and executes them if the conditions are met. These actions can perform server-side operations (such as writing to the database) or client-side operations (such as hiding or showing an element).
Let's review each action to determine if it's performed client-side or server-side. Note the following when reading the table:
The table only considers the cost of the action itself, not any additional workload consumption the action may lead to.
Example 1: triggering a page refresh doesn't consume workload, but loading the new page does (this is not part of the action).
Example 2: Similarly, triggering a custom event is handled client-side, but actions within that custom workflow may still consume workload.
Example 3: Setting a custom state is a client-side operation, but it may involve fetching data from the database.
Any extra workload from dynamic expressions in fields or conditions is not considered in this table.
Many server-side operations still include client-side processing, which means this list shouldn’t be read as black and white. We’ve marked them as server-side, since client-side doesn’t affect your workload.
Actions table
Action | Performed | Reason |
Sign the user up | Server-side | Involves user data processing and database operations |
Log the user in | Server-side | Authentication requires server verification |
Signup/login with a social network | Server-side | Uses external API for authentication, routed through the Bubble server |
Log the user out | Server-side | Involves session management on the server |
Update the user's credentials | Server-side | Requires server-side data updates |
Make changes to current user | Server-side | Updates user data stored on the server |
Send confirmation email | Server-side | Email sending involves server operations |
Send password reset email | Server-side | Email sending involves server operations |
Send magic login link | Server-side | Email sending involves server operations |
Create an account for someone else | Server-side | Involves creating user data on the server |
Check password for the current user | Server-side | Password verification requires server check |
Assign a temp password to a user | Server-side | Requires updating user credentials on the server |
Change the email for another user | Server-side | Involves updating user data on the server |
Log out other user's sessions | Server-side | Session management requires server operations |
Go to page ... | Client-side | Navigation is handled by the client. Loading the new page will incur workload, but is not a part of the action. |
Refresh the page | Client-side | Page reload is managed by the browser. Reloading the new page will incur workload, but is not a part of the action. |
Go to previous page | Client-side | Browser history navigation is client-side |
Open an external website | Client-side | Opening links is managed by the browser |
Add a pause before next action | Client-side | Delays are managed by the client |
Terminate this workflow | Client-side | Workflow control is handled client-side |
Create a new thing... | Server-side | Involves database operations |
Make changes to thing... | Server-side | Updates data stored on the server |
Make changes to a list of things... | Server-side | Batch updates involve server-side processing |
Delete thing... | Server-side | Requires server-side data removal |
Delete a list of things... | Server-side | Batch deletions involve server-side processing |
Copy a list of things... | Server-side | Data duplication is managed on the server |
Set a thing's slug... | Server-side | Slug setting involves server-side updates, as well as confirming the slug is unique |
Download data as CSV | Server-side | Data export involves server-side processing |
Upload data as CSV | Server-side | Data import requires server-side processing |
Delete an uploaded file | Server-side | File management involves server-side operations |
Send email | Server-side | Email sending involves server operations |
Send meeting request by email | Server-side | Email sending involves server operations |
Send Facebook Message | Server-side | Involves external API communication routed through the Bubble server |
Show | Client-side | Element visibility is handled by the client |
Toggle | Client-side | Element visibility is handled by the client |
Scroll to | Client-side | Scrolling is managed by the client |
Set focus | Client-side | Focus control is managed by the client |
Display data | Client-side | Data display is managed by the client, but may involve loading data from the server |
Display list | Client-side | Data display is managed by the client, but may involve loading data from the server |
Show next | Client-side | Handled by the client, but may involve loading more data from the server |
Go to page | Client-side | Navigation is handled by the client |
Show message (alert element) | Client-side | Messages are displayed by the client |
Animate | Client-side | Animations are rendered by the client |
Set state | Client-side | Custom state management is handled by the client |
Reset inputs | Client-side | Input reset is managed by the client |
Reset data | Client-side | Data reset is managed by the client |
Show previous | Client-side | Handled by the client, and the data will already be loaded on the server |
Clear list | Client-side | Clearing a repeating group is managed by the client |
Scroll to entry | Client-side | Scrolling is managed by the client |
Trigger a custom event | Client-side | Custom events are handled by the client |
Schedule a custom event | Client-side | Custom event scheduling is handled by the client |
Trigger a reusable element event | Client-side | Custom events are handled by the client |
Schedule API Workflow | Server-side | Involves API and server-side processing |
Schedule API Workflow on a list | Server-side | Batch API operations are managed by the server |
Set/cancel a recurring event | Server-side | Recurring events involve server-side management to set and cancel, as well as each time they run |
Cancel a scheduled API Workflow | Server-side | Canceling scheduled workflows involves server-side operations |
Dynamic expressions
Workflows can contain various dynamic expressions that sometimes involve the server, and the extent to which they do depends on the content of the expression. We delve deeper into dynamic expressions in the section below.
Elements
Elements are essentially client-side in nature, but still consume some workload to load. Additionally, elements can be set up in ways that require workload, such as setting a data source that queries the database.
To load and render an element is part of the page load workload process, and the number of elements doesn't change this processes value. After that, each element can contain dynamic expressions that require some server work:
Dynamic expressions
The element’s data source may be fetching data from the database
The element’s conditions may depend on server-side data sources
Any other fields that allow for dynamic expressions may also contain server-side data sources
Dynamic expressions
Elements can contain various dynamic expressions that sometimes involve the server, and the extent to which they do depends on the content of the expression. We delve deeper into dynamic expressions in the section below.
The placement of an expression does not affect its potential WU consumption. For example, two identical expressions placed in an element’s data source or in a condition will consume the same amount.
Element table
Let's review each element to determine if it requires server involvement.
The table considers a blank element placed on the page. Any workflows, dynamic expressions and conditions added to each element may require server communication.
Page Element | Performed | Reason |
Text | Client-side | Displayed and managed by the browser |
Button | Client-side | User interaction handled by the browser |
Icon | Client-side | Displayed and managed by the browser |
Link | Client-side | Managed by the browser |
Image | Client-side | Displayed and managed by the browser |
Shape | Client-side | Rendered and managed by the browser |
Alert | Client-side | Displayed and managed by the browser |
Video | Client-side | Played and managed by the browser |
HTML | Client-side | Rendered and managed by the browser |
Map | Server-side | Rendered and managed by the browser, but requires an API call that is routed through the Bubble server |
Built on Bubble | Client-side | Displayed and managed by the browser |
Expression | Client-side | Evaluated and managed by the browser |
Facebook Like | Server-side | Rendered and managed by the browser, but requires an API call that is routed through the Bubble server |
Facebook Page | Server-side | Rendered and managed by the browser, but requires an API call that is routed through the Bubble server |
Line/Bar Chart | Client-side | Rendered and managed by the browser |
Dynamic expressions
The components of a dynamic expression
Dynamic expressions consist of three types of components: data sources, operators, and comparisons. While all three can be performed server-side, the processing location of the operators and comparisons depends on the data source component.
The data source
The data source is any source from which Bubble can pull data. As the list below suggests, some of these come from the database, others come from the client.
Note the following when reading the table:
Many of the data sources in the table can be extended with sub-data sources that can change the location from which it’s processed:
Example 1: The Current user data source is downloaded on page load, and handled client-side after that. However, adding more steps, such as Current User’s Company’s Name may lead to additional queries to the server.
Example 2: Arbitrary text as a data source depends on the Text property inside of it. This allows for dynamic expressions, which may add queries even if the arbitrary text by itself is handled client-side
In the majority of cases, API requests are routed through Bubble’s server for security reasons, and as such are handled server-side even if the actual request is made to a third-party server.
Data source | Performed | Reason |
Current user | Client-side | User data is downloaded on page load, and available client-side after that. |
Do a search for | Server-side | Involves querying the database |
Perform a search using Algolia | Server-side | Uses external API for search, routed through the Bubble server |
Get an option | Client-side | Option sets are downloaded on page load, and available client-side after that. |
Arbitrary text | Client-side | Text is processed client-side, but the content in the argument may contain server-side. |
Arbitrary date/time | Client-side | Date/time is processed client-side |
Get data from an external API | Server-side | Involves external API communication, routed through the Bubble server in the majority of cases |
Parent group's thing / Current cell's thing | Client-side | Data is already loaded, and the query is not repeated |
Current cell's index | Client-side | Index is managed client-side |
Current page thing | Client-side | Data is downloaded on page load |
Element | Client-side | Managed client-side |
This page | Client-side | Managed client-side |
This element | Client-side | Managed client-side |
Result of previous step | Depends | Depends on the previous step |
Current Workflow thing | Depends | Depends on workflow context |
Thing now | Server-side | Backend database triggers are always processed server-side |
Thing before change | Server-side | Backend database triggers are always processed server-side |
Get data from page URL | Depends | URL is processed client-side, but may point to a data source that is fetched from the server |
Calculate formula | Client-side | Calculation is done client-side |
Calculate loan payment | Client-side | Calculation is done client-side |
Coordinates to address | Server-side | Uses external API for geocoding, routed through the Bubble server |
Generate random string | Depends | Mostly calculated server-side, but sometimes client-side |
Calculate sumproduct | Client-side | Calculation is done client-side |
Website home URL | Client-side | URL is processed client-side |
This URL | Client-side | URL is processed client-side |
Current language | Client-side | Language setting is managed client-side |
Operators and comparisons
Operators and comparisons follow the general rule of being performed server-side if one or more of the data sources are performed server-side. Because Bubble will attempt to finish the query in one process, without having to divide it between the server and client, the operators and comparisons will be context-dependent.
For example, if you are working with a search, such as the expression Do a search for Users:count the count operator will be performed on the server, and only the number of users (as opposed to the list of users) will be sent back to the client.
On the other hand, if you have already loaded a list of users into a repeating group, and reference this group using an expression like Repeating Group User’s List of users:count, the counting will be performed on the client, to save Bubble from having to transmit any data to the server.
The same is true for comparisons. Comparisons are used to compare two two compatible values, such as checking if a number is smaller, the same as or bigger than another number. The two numbers in this case would be the data sources, and whether this happens on the server depends on whether at least one of the data sources needs to communicate with the server.
Searches and filtering
Many dynamic expressions involve database searches, often initiated with the “Do a search for” data source. Typically, these requests are processed entirely on the server.
To determine which parts of the process occur on the server and which might take place on the client, ask whether the data has already been downloaded. In essence, if the data is not yet downloaded, the operation will occur on the server. If it has been downloaded, further filtering or processing can occur on the client.
This applies not only to when you reference the result of an already-completed search (e.g. Repeating Group User’s List of Users), but also when you repeat two identical Do a search for data sources in different expressions on the same page.
Filters
In Bubble, lists can be further refined using the :filtered operator. This operator works similarly to constraints: Bubble processes the list by eliminating entries that don’t match the provided criteria. The final results are the records that remain after this filtering process.
Dynamic expressions in Bubble process from left to right, so the :filtered operator applies its elimination after the initial search is completed. This means it filters the results after the search has applied any regular constraints.
However, this doesn’t automatically move the process to the client. Bubble will try to complete the entire request on the server whenever possible, within a single request, which doesn’t add additional WU cost to the base search.
However, filters added to an already-completed request will, in most cases, be performed on the client. For example, if you have a repeating group of users and want to further filter the list by a field like age (using an expression like Repeating Group User’s List of Users:filtered), this filtering will be done instantly on the client side, with no WU cost.
Per-row filtering (advanced filters)
As we explored earlier, searches generally use one or more constraints to eliminate records that don’t match, returning the remaining list.
However, there are scenarios where this simple process of elimination isn’t enough, and some dynamic data needs to be calculated for each record for the search to complete. This essentially adds an examination process for every row in the database, potentially multiplying the search effort many times over.