Fantastic reply @josh - one thing that i’m curious about re: scheduled workflows:
We often think it’s good practice to move important workflows to backend workflows in our apps, especially when they handle sensitive data or when we expect this action to be shared by multiple pages in the future.
App Organization and readability is a good reason for this too - we like to separate thinking about backend from thinking about frontend and make the pages as lean as possible so they are readable & anyone could replace some frontend work.
So Scheduled Workflows currently consume quite some WU, but if I understand it correctly, what you’re saying is a backend workflow is essentially the same as a frontend workflow which also do a call to your app’s API.
Since we are scheduling a lot of them at the current date/time, would it make sense to create some kind of ‘Run backend workflow’ action instead that always triggers directly & consumes less WU? Or does just the fact that it’s a defined endpoint increase the load on Bubble’s side?
I think having cron jobs / future scheduled workflows consume more WU makes total sense as you won’t be doing that for the majority of your app’s logic, but it would be nice to still be able to use the backend to organize.
I wonder if, apart from the message about WU consumption, I will be able to set the maximum monthly WU level for my application, at which the application, for example, will call a 404 page. Such a solution would reduce the financial risk for the bubblers. e.g. if I have 175k Wu to use, I could set, for example, max 250, knowing that I do not want to pay more without my knowledge, after exceeding and checking, I could change it to, for example, 300k to restart the operation, etc. This will reduce the risk
@josh this post highlights a question/request I also have regarding changing or adding to the workflow actions a trigger backend workflow, rather than just schedule a backend workflow.
This also brings up another question.
What impact on WFUs are expected to be incurred when we trigger a custom workflow from a page or in the backend, as well as schedule a custom workflow, trigger a custom workflow when data changes or trigger a custom workflow from a reusable element. Do these types of actions have impact on the WFU consumption?
Additionally, could there be a feature addition of allowing a custom workflow trigger to trigger itself, much like we do with recursive backend workflows? I understand it is on the agenda to create a better way to process lists, which would eliminate/reduce the need for recursive backend workflows, so perhaps the request from me would be to ensure the actions/features that make recursive backend workflows unnecessary for those to be available within custom workflow triggers or some other area of the page workflow actions.
I think you missed two points, one minor, one larger:
Minor point
When the url parameter on a single page app changes, all “on page load” workflows will run. If you have a workflow that say, updates the current user’s last active date field (like it does in canvas), that would run each time the page’s url changed. So if you have a single page app where you need to change the page’s thing often, that would run a lot and cost a lot of WU. I suggest allowing us to specify an on page load trigger in a similar fashion as the on condition workflow’s first time and every time. Perhaps something like a “full page load only” checkbox.
The second, larger issue:
A massive vulnerability is the auto-clicker (or any variation of what I will describe). Let’s say that you have a plugin demo app on the starter plan. A jealous competitor would only need to use an auto clicker on a button that creates a new thing to essentially shut down the app for a month or cost you thousands and thousands of dollars – or at least a headache in trying to contact support. And there is nothing that we could do about it
Now that each of our users are directly tied to a cost to us, we need tools to a) limit bad actors (such as setting a daily WU limit for users) b) see the WU cost that each of our users has accumulated in any given timeframe and c) be notified of unusual activity, such as more than 10% of our WU used within one hour. Getting notified on May 2 that our app is 75% of the way through our allotted WU is not good enough. We need pricing certainty, and the simple 75% WU notification and allow WU overage toggle that you are offering are not sufficient to run an actual business.
Here’s how I handle the page load stuff on our app if it really only needs to run on the first true page load (i.e., not just a parameter change). I use a page state that’s “page loaded” (yes/no, defaulted to no). On my workflow that runs all essential actions we want on only the initial page load, it has a condition to only run if the page’s “page loaded” state is no. Within this workflow, I change the state to yes, so it doesn’t run again on URL parameter changes, since those don’t reset states. Hopefully that makes sense.
Yeah, I’ve found myself doing this a few times recently as well, but I think that in the case of a beginner, using a template like canvas, they will not know to do this, especially when everything is buried within the convoluted header.
Even if Airdev were to optimize this, I think the principal remains the same. Minor, but it would be nice to have direct control over this within the workflow without the use of custom states or variable groups.
Could we get cacheable urls for data requests? So we do something like search (it generates a unique url with the hash of the payload), add :cache. It adds cache headers to the returned data and its cached by cloudflare cdn and browser.
For your major point: Great topic to bring up, and I’d love to see more functionality on the roadmap for things like:
Bubble alert to app owner when app reaches more than X% monthly WU in one 24-hour period, or single user reaches more than X% monthly WU in one 24-hour period (and please let us set up more than one custom alert; 3-5 would be great)
Workflows, conditions, etc. that factor in a user’s WU. E.g., if “current user’s WU used today > X”, execute an action. Could act as a backup to prevent bad actors, beyond what Cloudflare does.
Workflows, conditions, etc. that factor in the app’s WU. E.g., if “app’s WU used today < X,” run the workflow. Would help to limit running non-essential workflows if we’re experiencing a spike. For example, I have a workflow that updates a user’s “last time active”, but if we had a ton of SEO traffic one day, I don’t really need last time active to run for logged in users; I’d rather reserve that WU for our extra traffic.
Checked one our most used apps, in which we have quite some scheduled workflows by night.
WU between 02.00 and 07.00 before change (minimum): 9778
WU between 02.00 and 07.00 after change: 744
Reduction by more than 90%
Great work @josh and team! This is restoring our confidence. If only this was done before the announcement last week, would have save us a lot of headaches and grey hairs.
Even this new pricing is misleading. I ran a simple workflow to change a yes/no field of a user, then toggle a button after. That consumed 1.10 WU even though modifying database should just cost 0.5 WU. Where’s the extra 0.6 WU coming from… This was this morning
I suppose it would be good to have a single New Pricing Q&A thread closed for comments, where only @josh or any other Bubble team member can add new info based on community questions.
Suggestion… A lot of people, myself included, seem to track a users LAST ACTIVE status/time, by writing on to the database on pageload.
Obviously we’d now want to minimise this kind of thing, so maybe bubble would be so kind as to make “last active” function as a built in bubble nicety?
