With regards to optimization, I have a couple of things that I wish someone to hep me.
Do custom states consume WU’s?
@josh confirmed that operations in the front won’t consume WU’s. But TBH, I have no technical background to understand this. Does this mean that for example, instead of Do a search with constraints, if do a search with :filtered would consume less? What are the good practices to switch backend operations to frontend as much as possible?
Say, there is a data type A and related to current user who has multiple field values there. So (1) do a search for A: user=current user and (2) current user’s A. Is there WU consumption difference between the two?
I have a data type that currently had only less than 10 items while there is another that has 600+ items. When I check the log, WU consumption is much bigger for the former, at least 3-4 times. What can cause this?
No they do not. This is a good example of an entirely front end operation. (Note that SETTING the value of a custom state may consume WU, if for example, the expression is a Search.)
No. All searches cost WU. As has always been best practice, you should constrain your search to filter the results as much as possible before the list is returned from the database to the browser. (The number of things returned has an impact on WU cost.)
These are the same thing, basically, and should have the same cost. But the correct thing to do here (as has always been) is just reference Current User’s A.
What do you mean by “items” in this context? The number of fields on the thing, or the number of instances of the thing in your database?
Hi @keith, as a big fan of you, thanks for detailed help. I am so grateful.
My last question was : Type A(facilities) has less than 10 fields and Type B (metro stations) has 600+ fields, each representing metro station names. As in dev mode, I haven’t used those data yet; they just sit there. But, when I checked the log, Type A consumes nearly 30+% of the whole WU’s. That’s why I decided to ask someone possibly for help.
Anyway, if you can help me with showing any example of doing a same thing in frontend and backend in order for me to realize what that means, it’ll be so much appreciated… but maybe a little too much?
I’m still not quite sure what you mean, @yj.johnrhee. A thing with 10 fields will in general be less WU to (for example) access via a search than something with 600 fields…
Maybe include an image of what you’re talking about?
However, my first thought here is that, shouldn’t a “Metro Station” be a Thing that represents a single Metro Station? (Which would have a name, a geographic location, and other fields on it, such as operating hours.) And then, the list of all available Metro Stations would be the results of an unconstrained Search for Metro Stations.
(Though one might also make an object called All Metro Stations List that is a simple object that has a list on it that is a list of all the Metro Stations in the database. I’ve not experimented with this yet in the new world of WUs, but that might possibly be a “WU hack” right there.)
Please note that WU considerations shouldn’t concern us TOO much (now that they’ve been adjusted down) as the cost of these is MOSTLY aligned with Bubble best practices.
Maybe I should do a webinar after Bubble does theirs. Also, thanks for being a fan!
