As per the title.
If you have :formatted as text, you might think that only the yes or no expression would be evaluated. This is not the case.
Let’s take an example condition; Current User is Current User. This is always true.
Current User is Current user:formatted as text:
Yes: Do a search for X
No: Do a search for Y
Both Do a search for X and Do a search for Y will run, even though only one could ever be used. This occurs for nested :formatted as text expressions too.
Wow, that seems like behavior that’s just screaming to be optimized. Have you reported it?
I don’t think I’ve ever used a search operation in that context, but even with WU considerations aside, it seems quite inefficient with the potential to adversely impact performance.
And against this announcement from my point of view
But this announcement was before the parenthesis feature… maybe this has changed something?
@fede.bubble
Hmm, we sure about this?
I have an API call, the contents of which are dependant upon circumstance, so is something like “This Orders Payment Method is Invoiced:Format at text”
Yes = A particular set of values included nested objects
No = A particular set of values, not including nested objects
If both conditions run, it would be quite evident in the downstream processes from the API’s response. In other words, chaos would ensue. But this is not the case. Many other examples where this type of “If /then /else” logic is used in various other apps and they all behave accordingly…
To clarify, you mean both searches get called and evaluate their values, but only the truthy comes out as a result of the operator?
I too have never experienced issues with the operator and I use it in a ton. Though if true, not good for WU.
Exactly. I confirmed the behavior before I posted my response. It’s actually quite simple to reproduce. With the following setup…
…I see the following in the network tab of Chrome dev tools when I preview the page…
Both searches are run, and the responses are returned to the browser; but only the correct response - the user’s slug in this case - is displayed.
Definitely not. I also confirmed in App Metrics that WU charges are incurred for 2 searches.
Yes, they say they know about it and all formatted as text expressions are pre-emptively evaluated.
I’ll send the full response + test case tomorrow for people in the thread that are curious
Is this the case on both client side and serverside expressions?
I’m going to go on a limb here and say it will be similar to the responses I get when reporting bugs about WUs
I’ve reviewed your video and was able to replicate the behavior in your app when running the call in Postman myself, with and without the formatting as text.
I looked into past engineering context that we have internally on this, and indeed it seems like the current behavior is to preemptively load the values for both the yes and no outcomes, so that it knows what the value should be IF the formatted as text is yes or no. This is likely why you’re seeing the longer load time when the expression is included, even if formatting does not evaluate to yes in the end.
I understand this may be less efficient in some cases as this one, and I can incorporate internal feedback for this. That said, I hope this makes sense! Let me know if you have any follow-up questions. Thank you.
So it looks like this was an intentional decision that factored in the speed of searching vs the speed of execution.
Knowing how slow searches are in the chain of events, they just frontloaded it rather than making you wait for the search to complete.
There are lots of tradeoffs like this when it comes to WU.
Just bad decision to not follow how they execute conditionals since it is supposed to evaluate from beginning to end and when finding the first ‘no’ it stops evaluating the condition as it would fail, so they should just have done the same thing here…first evaluate the condition and then based on the evaluation run the appropriate search. Most likely this decision was not intentional with WU in mind (or should I say Performance instead of WUs since performance and WUs go hand in hand).
If you have a chain of logic with a yes/no somewhere in the middle, waiting on a search vs just instantly executing it is slower.
Yeah, could have been made before even WU existed. Either way, they’re choosing speed over WU. It’s not always the right call to prioritize WU, even from the perspective of building your own app. Petter Amilie does a good job of explaining this.
WU and speed (ie: performance) go hand in hand. If one is optimizing for WUs, they are also optimizing for performance. This I think has not been understood for sometime. Luckily, Emmanuel publicly stated as such in the AI AMA.
Sure, if the workflow would be loading both searches on page load in expectation that the workflow might be ran, but I would imagine that when a user clicks a button or a workflow series is otherwise triggered, the speed at which the evaluation of yes/no that can take place client side before sending a request to the server to process the searches is no different than if the searches are both performed prior to evaluating the condition and since that is two searches taking place, that is twice the strain on the server than necessary and likely is actually maybe underperforming since it needs to request twice, fetch twice, and send twice, all while running the series of actions.
I mean UI speed. Speed as perceived by the user. You can “waste” a ton of WU to provide a fast experience to the user.
I get your point. That’s actually why I asked this:
But more to the point, imagine a long chain of serverside actions with one yes/no in the middle.
This is definitely not always the case.. in fact, very often, as @randomanon points out, WU and Speed are polar opposites, and you have to pick one or the other to optimise for..
There are many cases where the most performant option (speed wise) is also the most costly in WU (and vice-versa) - although I suppose it depends on exactly what you mean by ‘performance’.
This is a perfect case in point - the more WU costly option of making both queries no matter what will also be the most performant in terms of perceived speed form the User’s perspective.
Bubble makes these kinds of arbitrary decision about data loading, I suppose to simplify things - but it would be nice if we had full control over exactly when data gets loaded.
I have not come across an example of this yet. Do any obvious cases come to mind where we as the developer are in control of the choice?
I don’t know why this would be possible as moving away from capacity to WU was meant to allow Bubble to charge based on computer power usage which tied into server usage which if something takes less time to process on the server it costs less in terms of WUs. Unless the idea of polar opposites is not implying they are inversely proportional as in this example where the performance improvement is not a 1:1 relation to the extra WU costs incurred.
I suppose that is true if we only focus on the idea that requesting two different searches from the server at the very beginning of the workflow series triggering makes it so that when the series reaches the one action with the formatted as text conditional evaluation taking place it is already available and so when the time that one action is executed and the condition evaluated is the only way to do something.
I tend to put faith in the idea that the moment the trigger takes place to start the workflow series, if that condition is evaluated at that moment and immediately there after requests from the server the one search necessary, that would be a more performant way to do things overall as there is less stress on the servers, which in my mind should be Bubbles goal and so confuses me why they would choose a negligible performance improvement (especially as they could have if intentionally focusing on such a decision, decided to just evaluate the condition immediately) over reducing overall strain on server, database I/O and resources overall (doesn’t bubble pay their suppliers for usage as well?)
So, yes, as it is something forced upon as as Bubble made that arbitrary decision, it is thought to have been made intentionally with the idea that the slightest increase in performance is preferred by the User (ie: app owner/paying bubble customer) and the extra costs incurred of WUs (paid for by the customer to Bubble) is negligible for the improved performance…which I’m not sure a conditional evaluation would take much more than some number of milliseconds.
Plus I don’t know if the size of the searches is something that is taken into consideration here, where yes, a small sized search might have the performance bonus at the expense of extra costs, but if the searches are large and take time to fetch, I don’t think the perceived improvement to fetch both first rather than evaluate first (again, I believe the only real difference here is order of operations since if we search twice first, the searches are cached, but the condition still needs to be evaluated on the client which would have the same amount of time required to be evaluated if the condition were evaluated first - meaning time to evaluate condition = 0.1ms and time to fetch = 1.5ms; doesn’t 'time to evaluate + time to fetch = time to fetch + time to evaluate).
I think ultimately if, the decision was intentional and a perceived performance improvement is had by running both searches first, it was maybe made with an assumption that ‘all searches are equal’. So, let’s say my Yes evaluation is for a search I expect will return 10 results, but my No evaluation is a search that may return 1,000 results. Would it not be more performant to evaluate first and return the 10 results? I just don’t see this as intentional for performance improvement. I believe it is an oversight, and will not be addressed since Bubble profits from it.
In this situation yes for sure. There should just be the simple checkbox to choose which approach to take, since as the developer, we likely will already know which searches are so heavy that the performance improvement is negligible at best.
Indeed, the ability to format the result of a Boolean operation as text was around long before WU.
I guess the good news is, Bubble is flexible enough that (at least in my experience) there’s nearly always more than one means to the same end; so I’d be surprised if there wasn’t a way to optimize for either WU or performance in most situations.
And while I personally have never used a search in that context and rarely nest :formatted as text operations, I appreciate being made aware of this behavior as it will likely inform decisions about how I craft Bubble logic in certain scenarios moving forward.
Sure.. there are loads, but probably the most common and obvious example is when making a header menu nav, with a nested structure - such as is common on e-commerce sites - with categories and sub-categories, and sub-sub-categories etc. (assuming those are all database items).
The most WU cost-efficient way to do it is to load the subcategories for a particular category only when that category is clicked - which can lead to a slow UX where the user has to wait for the subcategories to load every time they click a new category.
The more performant way to do it (from a UX point of view) is to pre-load ALL the subcategories, so they will appear instantly when the User selects a category, which is much better from a performance point of view - but significantly more costly in WU (especially as, most of the time, the vast majority of that data will not be needed).
So it’s a decision between less WU but slower performance, or fast performance but higher WU cost (in my view, in almost every such case, performance always takes priority over WU cost).
I don’t know why this would be possible as moving away from capacity to WU was meant to allow Bubble to charge based on computer power usage which tied into server usage which if something takes less time to process on the server it costs less in terms of WUs.
As I said, it depends what you mean by performance here…
If you mean the amount of processing by the actual servers that power your app then, of course, WU and performance are linked…
But if you mean (as I do) the perceived speed/snapiness/responsiveness etc. of your app by the end User, then they are often mutually exclusive.
For example, using list fields (or individual data requests generally) is very often faster than doing separate searches, but (in many cases) will cost more WU on the whole.
Nested searches can be faster than loading data to the page and filtering it client-side, but cost more in WU.
As I said, preloading data, or images etc. is always better for perceived performance, and is always worse for WU cost. It’s a choice between one or the other.
Yes, I think this is the difference, in the way we are defining performance.
And this example helps illustrate the difference in the definition we are using as I’m more inclined to say that performance is hindered by loading all subcategories on page load when they are not necessary, as for me the performance that matters most is the page load performance or just the speed at which actions process. But I can definitely see the point of performance being the perceived speed at which something takes place after the initial page load.
Yes, thank you for that. I appreciate that insight.
