So I am trying to speed up my app wherever possible. I remember reading on the forum somewhere that events with conditionals are slower than actions with conditionals. I’m hoping to get some ideas of best practices here.
There are two things to consider here:
workflow speed
workflow organization
Obviously all conditionals can be put into a single workflow (event) but that comes at the cost of drastically increasing the number of actions within the workflow and also significantly making the workflow harder to follow as conditionals get messy fast. Additionally, someone told me once that he always aims to have workflows have a max of 10 actions.
A potential way around conditionals in events is to have the conditionals on two actions that run custom events (assuming that forum post was correct that action conditionals are faster than event conditionals)
So basically this:
vs
Hi @cmarchan
I just finished reading through the entire book. It was a great read and a great suggestion but it didn’t directly answer my question posed in this thread.
Are you able to either point me to another resource that specifically answers this question or to provide a bit more detail yourself?
My statement was:
Events with conditionals are slower than actions with conditionals.
You are saying this is incorrect. I found the forum post I was referring to earlier:
Do you disagree with what they are recommending there?
Thanks,
Paul
I have seen apps with lots of conditions on the actions and also apps with many conditioned events. Have I compared them after tens of thousands of users stress-use them? No.
I would wager that this is not a subject to draw hard conclusions from.
Conventionally many seasoned Bubblers may argue for having conditions on the events rather than on conditions on the actions. Why? … given that Bubble runs actions in parallel when given leeway … a poorly structured set of actions may run into trouble when the app is “stress-used”. You may be getting away in dev mode but may not be setting things up to deal with high concurrent use.
My recommendation would be to focus on order of operations together with reliable conditioning.
To achieve the above:
Build all and any function/s into custom events and trigger those even if the custom event has only one action. This helps with order of operations.
Place key conditionality in events so that the nested actions are as few as possible.
Avoid as much as possible searching in conditions. If this is needed have searches coming from variables (using groups or RGs that act as states instead of custom states). This when possible of course.
I could go on … but this subject can grow into many directions … hopefully the above should make some sense.
Just two things though from a clarification of terms:
in your first bullet, you say “functions”. What specifically are you referring to when you say this? Do you mean a collection of actions?
when you say order of operations, I’m guessing that means that making sure that events and actions are in the correct order and triggered in proper sequence to avoid the comment you made at the top: "…a poorly structures set of actions may run into trouble when the app is “stress-used”
Lastly, when you say “even if the event has only one action”, I presume you would do this as bubble fully completes a custom event before preceeding to the next, so a custom event with one action ensures this action is run synchronously (i.e. run once everything else before it is run)
Sorry. One last question if you don’t mind. As I start to rebuild my app after reading that book, I expect I’m going to need a bunch of practice getting used to thinking through the most efficient way of doing things.
I have the two data types applicable to my cart: users and credit cards. Each user can have multiple credit cards.
What would be faster?
A search for credit cards with the constraints: created by = current user and default = yes
Current user’s list of credit cards:filtered with the constraints: default = yes
I’m assuming the second given that the list of credit cards for that user will be much smaller than the total list of credit cards of all the users, the only caveat is that the filtering is done client side.
The other option would be to create a group whose data source is the first bullet above and then I just reference that groups data whenever I need to display the user’s credit card.
The search … in other words an indirect dB model. List fields shall be avoided unless they are short (less than 100 items). There are more intricacies to this though.
Hi @cmarchan
I just posted another question with regards to app performance. You seem to know a fair amount about this stuff and I was wondering if you would take a look at the question if you had some time?
