An Update to Workload, Plus More Transparent Calculations

[josh]

Hi all, following up with a few quick updates and some answers to a few of the questions:

• The pie chart now shows both % and absolute WU. Thanks to the couple people who made that suggestion!
• You can see WU usage by your workflows in the Logs tab now
• Re: the reports of “Deleted” pages showing up in the pie chart, as people on this thread correctly surmised, that was coming from visits (probably by crawlers or script kiddies) to pages that didn’t actually exist. We can confirm that we do not use Wordpress as part of Bubble’s primary tech stack! As of this morning, we changed the code such that we don’t count any WU from visiting missing / 404 pages. If you are seeing new data with mysterious pages, please file a bug report. Note that you will see “Deleted” in the case where: a) you had a page, b) someone visited it, and then c) you deleted it afterwards – that was what the “Deleted” indicator was supposed to be about.
• We are still following up on a few other bug reports about WU calculations, but should have them all fully and investigated and fixed well before we actually make the new plans available on the 1st. All the outstanding issues we are currently investigating are minor and should not make a meaningful difference to your app’s workload computation.

To answer some of the questions:

@lizzie

Is there a commitment to keep the WU calculations open from now on or will they be ‘proprietary’ in the future and subject to change. I would hope they would always be public to help users and new customers to understand.

We plan to add the chart shared in my original post to our documentation, and to keep it up-to-date. The most likely scenario for us making a change would be us adding a brand new feature to Bubble, which would not impact the consumption of existing apps until they start using the new features. We may also choose to reduce WU weights in the future to pass along improvements we make on our end.

@jonah.deleseleuc

Inbound API calls (webhooks) have a fatal flaw: when you try to return data, the workflow will only return data after every action has completed (even if it’s the first action)

I’m passing this feedback along to the team: we’ve been tackling a number of similar quality-of-life improvements lately and always hungry for more to add to the list.

@hafizaliimrankhan

Second, what I would really want to know, is what is this new pricinng model will bring change?
Will we have no issues with scaling?
Will we also solve GDPR issue?

How this increase in price would change something for the users?

Yes, one of the main goals of the pricing change is to enable us to hire engineers faster! We would like to be roughly doubling the size of the engineering team each year for the next couple years. Right now, each one of our engineering teams is stretched very thin across a wide surface area, which limits the number of improvements we can make in parallel. As we hire more people, it frees us up to move faster, including on improving our scaling and our geographic hosting.

@tylerboodman

Can you make it so Dev WUs are a different color on the chart? Then we get a quick overview of was it just devs playing around or if user traffic actually increased?

That’s a good suggestion, I’ll pass it along to our design team

@aaronsheldon

I can tell you regression is an invalid methodology for developing your pricing model. It is well documented that memory and time consumption in computing is governed by “power law”, also know as “fat-tail”, or “black-swan” distributions. These stochastic processes violate the assumptions that underpin regression models.

This is a really interesting point; thanks for bringing it up. After this morning’s updates, which were driven by investigation into use cases reported to us by the community, we’ve adjusted the weights from the original regression, so I am not sure going back and trying a geometric mean would be a net improvement on what we just released. Also, while we are aware that infrastructure usage follows a power-law distribution across different applications, our analysis was more narrow: we were looking specifically at the relationship between different activities and the time it takes our code to run a single execution thread containing those activities. That relationship has more to do with the implementation details of our code than general principles about computation: you can write code with any kind of relationship between its inputs and its execution time (ie with different big-O values). In practice, we found that a linear regression performed fairly well against the code we were analyzing. Very fair question though!

@roman.furman0

So, what about frontend actions? (Like execution javascript, set state, reload page)

Front-end actions do not consume workload (although reloading a page sometimes involves hitting the backend). For the Bubble power users out there, an easy way to tell if something is purely frontend is opening the network tab of your browser and seeing if it kicks off a new request to the server – if no new requests, it is frontend only.

@NoCodePete

do Data API requests count as DB searches and/or DB creates/edits? if not, is it in theory cheaper to use the Data API than native create/edit/get DB items?

They do count, so I do not anticipate this being a cost savings.

@boston85719

please add ability to searches to only return a set of fields designated. I’d like to be able to say please don’t return Modified Date or Created Date or any custom field I may have on the data type to be retrieved

On our list!

@boston85719

Please add functionality for slugs to be recognized in the get data from Url extraction expression. This will help migrate searches into single item returns more easily than the :first item operator, which I’m unsure of if that operator in effect results in a single item return or a full search.

Thanks for the feedback – we’ve been taking a look at our url structures and will likely make changes to make them more efficient and usable

@boston85719

Please extend the time before an api call times out up from the current 30 seconds.

Look out for an announcement related to this coming very soon!

@boston85719

Please add features to recursive backend workflows that could enable conditionals to shut down infinite loops or other WFU consuming developer mistakes. Someway to count the recursive runs and stop after X number.

This a good suggestion. Our goal is actually to have better ways of manipulating data than recursive API workflows (which are not intuitive and easy to make mistakes with). We are looking into building the equivalent of “for” loops, as well as efficient bulk data transformations.

@asked111

Does a “make change to a thing” take up more WU as a fronted workflow or a backend workflow?

No difference. When you have a “Make change to thing” on the frontend, we simultaneously execute it on the frontend so that the browser updates immediately, while also executing it on the backend (to update the database). The frontend execution does not consume WU, the backend does, so it is equivalent to a backend workflow. In practice, though, running a backend workflow generally involves an additional action to schedule it, which would cost additional WU, so a frontend workflow is the way to go if there isn’t a specific reason to use a backend workflow.

@yj.johnrhee

So 100K WU’s each month ir just one time thing?

Each month. I updated the original post to make it clearer.

@devease

1.Will we be able to be notified when the app exceeds a certain threshold of WU that we could define? Ideally we could have a webhook for this so we can use it where we want either inside or outside of the app. This would help us control the use of the app, manage development errors and manage possible attacks.
2. It would be interesting to be able to have access to this data (downloadable or via the db). Not in order to check the billing, but to be able to analyze app usage. I’m thinking for example of page loading. This data is often used in tracking. If we have access to this data it may limit our use of tracking tools.

Thanks for the suggestions! We’ve built emails and in-editor alerting as your app approaches its max WU consumption, and the ability to cap WU spend if you do not want to incur overages. I like the idea of being able to customize the alerts and to use a webhook, passing the ideas along to the team. I’ll also pass along the idea of accessing the data to supplement / replace 3rd party analytics tools.

@jade1

I imagine that the change of WU allowed in Free plan and paid plans also induces a change on the calculation of break-even points between tiers.

The charts still work as-is, actually. The way to think about the free Development WU on paid plans is to not count it when calculating your total WU. We are going to update the display in the editor to do that automatically; it will show you the Development WU used, but will show a total with the free Dev WU automatically subtracted. That said, check out the calculator we released – it is much easier to use that then the break-even charts!

@samantha_hu

Just want to be sure that the 100K free development WUs/month given on all paid Apps is “additional” on top of each plan already exist WUs per month? For example: Starter plan 175k WUs/month + 100K free development WUs/month ?

Yes, exactly. To give a concrete example, if you are on the Starter plan, and one month you use 100K Live WU, and 120K Dev WU, your total is 100K + (120K - 100K) = 120K, which is below the 175K Starter plan limit.

@treb.gatte

Second and this is a quibble as a Power BI data visualization expert. Pie/donut charts are not very useful when you have more than 3 values and I’m getting nearly 20+ slices. Can we use a stacked bar chart instead to visualize consumption? This makes it easier for comparison as our eyes can detect as small as 2px variance in one dimension, which a bar allows. Also, it will scale more easily for those with more complex applications and a lot of queries, etc. being used.

This is on our design team’s radar!

@gaurav

Will client-side actions consume Workload Units (WUs) even though they do not incur any costs for the Bubble servers?

Anything that does not result in a request to the Bubble server (as seen in our network tab) won’t consume WU

@gaurav

How does the WU system affect auto-binding? Since each keystroke attempts to save data to the server, will it be billed per keystroke per field?

We de-bounce auto-binding, meaning that we wait for the user to finish typing before updating the server.

@gaurav

Many Bubble users employ page URL parameters to switch groups and manage UI navigation.

• Since page loads are now billed, will such a navigation system incur charges per URL parameter change?
• If I understand correctly, Bubble also tends to run page load workflows on URL updates. Will these be billed as well?

Only actual page refreshes that load the whole page HTML from scratch consume WU. Updating the URL on a single-page app will not consume WU.

@gaurav

• How does the WU system interact with Bubble’s geographic position data type?
• When attempting to display location data from, for example, a plugin element, Bubble seems to automatically retrieve the relevant geographic field from Google.
• Since this involves an API call, will it be billed?
• If the source list or numerous markers on Google Maps update when the map is moved (e.g., a search with constraint of specific items within a 10-mile radius of the current position), will each location change be billed, no matter how minor? And if 1,000 users are moving within an app, would this result in cumulative billing?

The only API calls that consume WU are ones explicitly created by the user, not backend ones that Bubble does to support our geolocation and maps features. That said, I am going to double-check to make sure that we are not counting that workload.

@gaurav

To the best of my knowledge, Bubble retrieves complete records for any given search, while SQL typically allows for the selection of specific fields. How does the new billing system account for this?

This is on our list of things to improve to make Bubble faster and more performant. Today, though, Bubble does fetch the entire record