Still working on my first app in Bubble. I’m use to coding so this is a new learning experience.
The part that I think is confusing to new users - is Bubble is designed as a no-code platform that anyone can use -
then someone came along and threw in the whole pricing configuration and threw a ton of confusion back into a platform that was supposed to be easy to use.
It’s like you need to learn Bubble, then you need to take classes on figuring out how much your app will cost monthly to operate. A builder that was advertised as ‘for everyone’ then turned around and confused everyone.
Hopefully, it works out for the best for everyone.
Who do the email notifications go to? Are they to all editors? Just the admin, or just the paying user?
I’d probably want them to go to everyone that’s an editor on the app - more likely folks will be able to react that way. But I suspect other agency use cases might want to limit this to just the agency or some other specific email.
On the infinite loop protection, what kind of visibility will be available to know that this happened? Will there be an error log? An alert somewhere? If the app is unexpectedly stopping a workflow, that could impact data integrity (even if it is simultaneously saving us from an infinite loop issue) - so as a developer I need to know that this happened so I can both address the underlying issue and potentially address the specific data that was being updated.
@josh@emmanuel and Laura, Can anyone explain why this is not the highest priority in terms of effort versus value?!?
Customized workflow notifications (which is great assuming they comes in timely - not 22 hours AFTER the spike ENDS) are kind of putting the cart before the horse without the actual algorithm?
As it persists in billing for mysterious and unquantifiable WU consumption overages, Bubble is practically courting a massive class action lawsuit.
Is WU determined through a mathematical calculation, or is it purely arbitrary?
If WU are actually being calculated, then it follows that someone had to create the calculation. Is the person still alive?
If so, why can not he/she give the calculation to someone on the team to put into words? And, yes, it may not be a straight linear calculation (for example, setting the slug when there are duplicates because Bubble does not add leading zeros, which complicates things), but so what? We are talking about millions and millions of dollars being charged without any calculation…
Without any knowledge of Bubble’s internal workings, I was able to construct a fairly basic (but accurate) WU calculation for slugs and a variety of other types of searches. I did so by guessing why the WU would be X amount and then changing some of the variables to see how the WU changed, allowing me to determine what an actual WU activity was through the process of elimination. Could a member of the team, who is knowledgeable about the activity’s actual meaning, compile the calculations for us?
P.S. If the calculation is not forthcoming in the near future, could Bubble at least offer a function on a “thing” that returns the number of characters of data the thing contains?
Ths is funny, because if the WU represent the system work for a request, I understand that my own searches should be cheaper than leading zero method based on MS. This test also highlight how much is impossible actually to evaluate the WU result of some actions. So I wonder how Bubble will be able to provide tools/table that will really help to calculate cost actually… (By the way, your table slug value is probably not aligned correctly for the leading zero method)
In dev, it tends to be very spiky. I may have to do a bulk data processing operation across a bunch of rows in the db which would take a lot of WU, but that wouldn’t likely happen once I go live.
It’s a nice-to-have, certainly not a blocker. I would be very happy to use the new feature with a single threshold.
I can’t speak for back of the napkin numbers I wrote down a few weeks ago but I will tell you that running the same exact action would have different MS numbers every now and then. (Is it because it’s queued based on other server activities? )
More importantly, and an illustration of the total lack of transparency, is setting a slug whether natively or doing a customized search, a server-side plugin action?!? Based on the plain language of the activity I’d say it’s not but who knows?
Maybe I should be more explicit. Not so much a WU calculation as much as a walk-through for common actions; which WU activities are triggered by the action and what parameters and context of the action cause which additional WU activities…
E.g., when setting a thing’s slug, that is not a server-side plugin activity so the milliseconds it takes to complete that action doesn’t impact the WU for that action
OR when displaying a RG on a page, each result returned before advanced client side filters is considered a result (for WU activity #6, Each result returned from the database) and the characters within each field displayed in the RG or used in a client side filter is charged (WU activity #5 Each character of data returned from the database) and the characters of a thing that is nested within a RG’s thing are only charged IF ( fill in the blank?!); otherwise the only characters charged for that thing is its UID ( ?!?)
@georgecollier@Jici and others: I really appreciate you taking the time to explain the frustration you have with the current tooling and information. We do have the manual and the logs tab, but I hear you that for what you’re building, the granularity isn’t enough. We are working on updating the manual, as well as building more observability tools that should address some of the challenges you face today calculating WU.
The issue @laura.oppenheimer is that with this actually, we don’t know really what used WU because it’s incomplete or incorrect. Look at this post: PSA: Large databases DO cost additional WU (edit, turns out they don’t) - #6 by Jici Can you find the answer? I cannot… This is a huge problem because there’s
A) A bug/error that make user pay for WU that shouldn’t
or
B) Missing informations about WU in manual.
OR
C) Wrong calculation for total?
And even if I send a support ticket about that… there’s so many report that Bubble team is not able to answer about WU that I don’t want to take time for that.
Logs are borderline unusable unless you know exact time and dates. Even a few hour - 1 day search in logs tends to crash.
Most of my apps have our own built in logging system to even be useable which under WU isn’t cheap to just have access to something that should already work.
(If I’m not mistaken, even bubbles support team uses a different access point to logs than we get from my experience with them)
I was being generous if you add in a keyword, a user, and filter down to just one or two of the filters checked you can get a few hours to a day span depending on app traffic.
Very good question, I’m curious myself. One could assume that since it’s not listed it’s not charged but that logic has betrayed us multiple times before considering bubble likes non transparent pricing over a year after its launch
^^ The ‘contains’ search bar is more or less broken which further exacerbated this (every time I’ve tried to use it it returns no results unless it’s just a single word or something - if I search for text that was sent in an email, it won’t be found even if my search is case sensitive-correct.
Yep, on large apps we all create an option set for Log Type and create a new Log (data type) when something relevant happens. That allows us to more easily track things that go wrong, e.g you can send an email using a trigger when more than X errors in last Y hours). This doesn’t work for WU which would be fine if the default logs worked but they’re not that useful if 1. we can’t search them 2. there’s no breakdown other than the total WU
To be fair this thread has now thrown out a million ideas, but here’s my realistic priority list, putting (what I guess are) simpler to develop features first.
A list of everything we’re charged for. Come on, it’s absurd this doesn’t exist.
WU breakdown in the logs (X WU for P + Y WU for Q = Z total WU for action). The manual can only help us calculate to a limited extent as, as you know, Bubble can be used in so many ways that no examples you could provide could possibly cover every situation.
Cheaper ‘Get Thing by Unique ID’ instead of Do a search for:first item
Track WU usage by user (email or unique ID for logged in users), which should be able to view the drill down pie chart but for a given user rather than the entire app.
Specify fields to return in search (in an alpha release, don’t even bother with issue checking - non returned fields should just be ‘empty’)
Redesign logs (very useful for things other than WU)
I promise the above list is a pretty fair representation of what every user that matters wants… and other users here will attest to that.
@laura.oppenheimer More Evidence that a basic list is needed (and perhaps further evidence that the WUs or logs aren’t accurate?)
Basic DB trigger: WU: 0.77
What could lead to that #?
.05 for DB trigger ( #7. Each data trigger workflow initiated)
.6 for the (#16. Running a server-side workflow action - see image below showing that the DB trigger has a workflow action - I would have thought that WU would be when the action is run which is separate but I guess not)
So we have .65 WU
Where’s the .12 coming from?
The DB trigger is simple and just looking at one field which only has ~15 characters ( #5. Each character of data returned from the database); that’s nowhere near .12 (even the WHOLE thing, which certainly does NOT need to be retrieved is well under 1k characters so that would only be .03 at most (1,000* 0.000003).
Same for #3. Each millisecond spent executing a server-side plugin action → still can’t cover the .12 as it took 21 seconds to run (see below) which is a measly 0.0105
Weirdly the log lists this DB trigger as 0.7 WU which is inconsistent but where’s the extra .05 (0.7 - -.65) coming from? and how is it an additional .07 more than that on the chart? Is the log incorrect or the WU graph or … ??
And this DB trigger doesn’t have complex search or page load or external API so what activities can it be even if you want to interpret Bubble’s vaguely worded WU activities as broadly as possible!?! Anyone have any clue?
To recap, let’s list the 19 possible WU activities and whether they can be triggered for this DB trigger:
No DB Search (#4, #6, #11, #12)
No Inbound / Outbound API (#13, #14, #15)
No SQL Connector (#17, #18)
No CRUD Actions *#9, #10)
No Page Load (#1)
No Server Side plugin (#2 - and we don’t have .2 available anyway.
there’s no call to watch a search for real time updates or add to scheduler (#8, #19)
All that’s left is: #3 - MS which can’t be .12 #5 - Characters returned which can’t be .12 #7 - DB trigger - .05 already included and #16 - server side WF running - .6 already included
Bottom Line: Is the WU .70 OR .77 and how on earth does it get above .65 (other than a few charachters which is not enough to add anywhere near the .05 or .12 that was added)?
George, Nice I Like that. But shouldn’t the DB trigger itself (bottom row in logs include the .05 for the DB trigger? and if it does then the scheduler is too large to be here? and the hamster wheel goes round and round…
Also for the scheduler, does scheduler activity apply when you don’t add a delay to the WF?
)
if you add in a keyword, a user, and filter down to just one or two of the filters checked you can get a few hours to a day span depending on app traffic.
??
