Planning for workload

This article series covers how to work with workload in practice, and tips and tricks to reduce workload consumption. If you'd like to learn more what how the metric works and the different processes that spend workload, you may want to read the article series below first:

Article series: Pricing and workload

The workload metric gives a glimpse into how much server power your app is using. Think of it like a car's fuel gauge – it shows how much energy we're consuming as we drive our app forward.

But here's the interesting part: while we do want to be mindful of our "fuel" consumption (after all, it can influence hosting costs and scalability), it's just as important to ensure our app delivers a smooth ride for its users.

It's all about balance. In this article, we're going to explore how to plan for workload in a way that keeps both the app's performance and user experience in harmony.

Thinking about the user experience

The user experience encompasses how your users feel and interact when navigating your app. Does the app feel snappy? Is it well-designed? Does it solve problems efficiently?

Think about it: our daily lives are filled with interactions in different applications: we order food, plane tickets, tourist experiences, and taxis in seconds. We keep track of customers, projects, tasks, and fitness goals. We chat, and attend live video meetings with friends, family and colleagues and send files across the planet in seconds.

All of this feels second-nature; it's simply how the world works. But think about it: some of the processes being performed are highly complex. They can involve huge, complicated databases, GPS coordinates, payment systems, and different kinds of artificial intelligence, all wrapped up in a good-looking, easy-to-use application.

Successful apps work hard to hide how complex they really are – that's why they are so successful. Your users will not care how much advanced machinery is working under the hood, as long as they have a smooth experience that solves their problem quickly.

This understanding is crucial as you plan for workload: you need to balance the UX with the optimal workload consumption. The underlying point in that is of course that most apps need to spend workload in order to give your users the experience they expect – but with careful planning and good design you can avoid spending more than what is needed.

Three levels of decision making

Planning is all about making decisions. Should the app look like this or that? Should this feature work this way, or that way? Is it needed at all? In our general section about planning your app's features, we explore how to think about your app in versions and not let delay your release.

When it comes to striking the balance between workload and UX, you can think about decision making in three levels:

1. Save workload at no expense to UX

If you can implement or change a process that saves you workload at no cost to your user's experience, the decision is easy: you can go right ahead and implement it.

Keep it mind though that this too can lead to ; you can implement it right away or you can plan it for a future release. While we won't delve into the specifics of when to make this change, if it aligns with your development timeline, there's little reason not to go ahead with it.

2. Save workload at a slight cost to UX

The second level involves making a slight sacrifice to the user experience in order to reduce workload consumption. It's essential to understand that compromising isn't always negative; it merely demands careful evaluation. There are instances where tweaking the UX can result in a more efficient app, while in other situations, the user experience should take precedence over server efficiency.

Choices within this realm aren't necessarily binary. Thoughtfully weigh the options to ensure that any modifications don't compromise user satisfaction. We'll delve deeper into these considerations and strategies throughout this series.

3. Save workload at a major cost to UX

At the third level, we are making cuts or changes in the user experience that user's may find to be reducing the overall quality of the app. If you find yourself in this level, you may think about what we said in the introductory article: that workload is there to be spent – you would never expect your car to run without fuel or electricity.

If workload concerns compromise your app's primary function or its ability to address a specific problem, you might be placing too much emphasis on it. Remember, the main goal is for your app to effectively serve its intended purpose, not to race towards the lowest possible workload consumption.

That's not to say that you should not spend time reflecting over points that consume a lot of workload but are important to your users: there may be methods or UX changes that lowers consumption in a more UX-friendly way than you initially thought.

What consumes workload?

In our Pricing and workload article series, we have a chart that shows how different activity types in Bubble are weighted when workload is calculated. While this chart gives an accurate factual image of the way workload is calculated, it can still be tricky to translate into real-life scenarios in your own app.

So instead of looking at precise, specific activity types that consume workload, we'll cover how different design choices in your app can affect it. The aim is to make it easier to make informed decisions as you go about planning your app.

Changing data versus loading data

The first common generalization that we should get out of the way is the difference between changing and loading data. Or rather – the lack of a difference between the two. Let's see what that means.

It's easy to think of workload as the work that the server is doing. That definition is not wrong in any sense, but it can interfere with the mindset you need to plan an optimized app. It's tempting to think of server work only when the server is performing some sort of action, like or importing a CSV file. But it's worth noting that this is only half the truth: searching for and fetching data is also work, and can be equally or even more taxing on the server and costly from a workload perspective.

So while it's true that actions (and bulk actions in particular) can be resource-demanding, you should not ignore the work the server is doing to search for, send and aggregate the data that already exists. You may find that using the Do a search for data source repeatedly can consume a lot of server resources, and having this in mind can help you plan your app in a different way.

We'll get into this in more detail in subsequent articles.

One-time expenses versus running costs

It can also be beneficial to view workload through an economist's lens: one-time expenses, even if steep initially, can often be more manageable in the long run than continuous operational expenses.

One-time workload costs can happen for numerous reasons:

• Importing or changing large amounts of data at once

• A sudden spike in traffic to your app that subsides after some time

• Batch processing or running a series of complex workflows in a short span

• Initial setup processes such as syncing with third-party services or apps

• Major updates or migrations which require significant recalculations or data transformations

• Running intensive, but infrequent, analytics or reporting functions

• User-driven events, like large file uploads or mass data entries during specific campaigns or promotions

• Special promotions or launches which result in short-term high user activity

• Mistakes, like unknowingly running a more times than intended

This list isn't comprehensive, but it highlights that certain events can cause a temporary surge in workload cost. However, this doesn't always indicate that you should allocate a significant amount of resources to mitigate that load. If such events are rare or one-offs, it might be more practical to absorb the occasional extra cost rather than over-optimizing for it.

Bubble provides several flexible options for handling workload usage that exceeds the limits of your . For more details, see to the article section below:

Article section: Plans and Billing: Additional Workload

Common causes of high workload consumption

With those two points out of the way, let's look at some of the most common causes of high workload consumption.

Searching for data

Searching for data is among the more taxing tasks you can give a server. When you Create a thing, you are working with one thing, whereas a search can work with hundreds, thousands or even millions. While Bubble performs a lot of magic under the hood to perform searches efficiently, it's still a simple truth of database operations that searching is a fairly costly operation.

Like with any other workload consideration, it's not one search that will incur costs: it's when it happens frequently. For example, if you have a public app (not requiring a login) that shows the results of a search on every page load (such as an eCommerce site showing products), you may find that this one single search is responsible for a high percentage of your workload.

Since it happens every time the page loads, it can become a major consumer even if the page itself is fairly simple.

Nested searches

The same is true for nested searches. Let's say that you are loading a list of client companies in a CRM and displaying the result in a repeating group. Two data types are used here:

• Company

• Employee (connected to a Company)

In each row, you also search for and count the number of employees in each company, looking something like the table below:

Company	Employees
Company 1	1500
Company 2	2000
Company 3	800

How many searches are performed in this example? You may think one, since the list is showing one list of companies. But the actual number is four: one search for companies, and then three searches/counting of the employees in each row.

In this example, we're showing only three rows, but if this were to grow to hundreds of rows, you could potentially be performing hundreds of searches every single time the page loads: this can quickly lead to an overconsumption of workload.

A possible solution to this is to instead save the number of employees in a number field on each company, and update it each time an employee is added or removed. It's a bit more work for you as the developer, but can drastically reduce the work for the server.

You can read more about how searches affect WU in the article below:

Article: Searches and workload

API requests

Both the and can be highly useful, but if not set up and monitored it can also lead to a high workload. For example, if you don't require to before accessing the Data or Workflow API, the volume of requests can grow faster than you anticipated or intended (since anyone can access it at any time). Malicious actors that identify the of your data types or workflows can also theoretically flood your system with requests if they don't require authentication.

Likewise, if the requests are running particularly complex API workflows or bulk Data API operations, your app's API can require a higher workload than your actual users. Keep in mind that these requests too require server resources and will add to your app's total workload consumption.

Generally, you can avoid surprises by:

• Controlling the volume of requests by requiring authentication

• Avoid unnecessarily resource-demanding operations

• Disabling any API workflows or data types that you don't need to be accessible from external systems

Bulk operations

Bulk operations in Bubble typically are performed using one of the methods below:

• Importing CSV files

• Running

• , or using the Bulk tool in the database editor

If a bulk operation is performed once, it can make sense to simply accept the temporary increase in workload (as we explored earlier in this article), but if it is performed repeatedly, it may make sense to look into:

• How often it runs

• How resource-demanding the operation is

Many bulk operations are performed more often than they need too. Let's say for example that you are running a bulk operation every hour that updates some sort of statistical report. If you are doing this for one client, it may be fine, but let's then extend this to a multi-client app: every hour, statistics are updated for every client in your app.

The intention behind this is good: you use one hourly bulk operation to update reports, rather than running it every time the page is loaded. But still, an hourly bulk operation for every client in your app can quickly become unsustainable.

In scenarios like this, it can be helpful to consider a few questions:

• Should the operation run every hour even if the user hasn't logged into the app for a while?

  • Instead, you could run it when the user logs in, if a specified number of hours has passed since the last time it was executed

  • You could also run it less frequently (like once per day), and when the user logs in like above

  • You could also consider asking the user to manually run the operation; maybe the hourly up-to-date reports are not as important to every client as you think: an Update button could be enough for most clients. If only 10% of clients clicked that button, you have reduced the workload consumption of that operation by 90% with just a simple design decision.

• What data should the report include? Do you need to aggregate all data, or can you simplify and reduce the number of data points the operation produces?

In this example, we focus on statistics, but the same two questions from above are worth considering for every type of bulk operation:

• How often it runs

• How resource-demanding the operation is

Try to visualize how an operation can grow, especially when performed on a per-client basis: what you consider an hourly operation can become a thousands-of-times-per hour operation as your user list grows. Maybe you can set up a schedule that is not as frequent, or even dynamic per user and their pattern of app usage?

Page load

In the next article, we'll look into one of the most crucial workload-related decisions you can make: what happens when the page loads? Let's dive in.

Article: Page load