Sorry if this is a duplicate but I could not see any similar posts.
Create a for next/do while loop in the front end rather than API.
You can use the Schedule Custom event action with a delay of 0 to create a loop. You need two workflow Custom events (CE). First create CE1 “For” which contains the workflow code you would like to execute. The last elment in the workflow needs to schedule a second CE with a delay of 0 seconds with the constraint that ends the loop (so it only executes if the loop needs to continue). Create a secound CE2 “Next” with only one workflow elment, “Schedule” CE1 with a delay of 0. With these two custom events you now have a recursive loop that executes on the client side. Note: I would not recommend this for use cases that involve DB updates, since it is likely more effiecient to do this on the server side.
You could also use a Backend workflow to accomplish the same. The last element in the workflow would call the same workflow based on a condition being met/unmet.
Absolutely, recursive API calls “loops” are regularly used.
I always use APIs if the workflow involves a DB action since it is much more efficient and mitigates a workflow being interupted during the loop (or a DB action) which would result in the DB being incorrect.
There are use cases though were using a client side loop can be preferable since it does not incure a communication propogation delay. We get so use to 30ms or less packet response times while on high speed networks we sometimes forget that this is not always the case for all users. Hence, if I can do it on the user device I will (depending on the complexity of course). Many programmers create applications on high-speed networks were they do all thier testing, then the app performs terribly in the “real-world” when mobile users have spotty service or limited data plans.
Thank you so much for posting this tip! I used this setup to replace several recursive backend workflows that were really slow and used a ton of WUs. I tweaked your example to create a series of front-end nested loops using three custom events. It is very fast and reduced my workflow units substantially.
You are very welcome. Just in case your back end workflows do DB writes, if not cool.
I suggest that it is important not to use such front-end loops if you are doing multiple DB updates that require writes to different tables that must remain in sync. One problem Bubble has is that it does not use DB Transactions. This means; if for some reason the workflow gets disrupted during recursive DB writes it is possible for the DB to be out of sync. Normal DBs handle this by returning a Transaction error that allows you to “Rollback” the DB and hence restore it to the previously known state. Then, you start the whole sequence over again so that the DB ends up in the known state. Unfortunately Bubble does not support all best practice DB best practices.
One last note, that it was widely suggested that DB actions be handled in the back end if users are using mobile devices. That way if the phone looses connections momentarily the DB action does not get disrupted. Sadly there are “Expert” videos on this.
