You’re probably concerned about a non-issue. It’ll get obvious real fast if there are any issues.
This is actually super-handy and performant. It can help you minimize execution blocking BS that might happen in your app. For example, I have pages where there’s a bunch of initialization that needs to happen, but it can totally be completed in the background while the page loads. So, on page load, I kick off an API workflow to go fetch a bunch of stuff, ping some external APIs, etc. Doing it in this way doesn’t block page rendering.
Kicking off a Custom Workflow is also like this. That process (in most cases) doesn’t block anything else going on on the page (like, you don’t have to wait for the status bar to update, etc.). So that’s really cool when you can get away with it.
But back to my original comment where I was musing about “it might be cool to build your app in such a way that your workflows are not ‘stuck’ on a button or whatever”:
What I was saying is that, if one DID fancy to construct their workflows such that any non-custom workflow was just a single step that kicked off a Custom Workflow, one might have to be mindful of potential issues from asynchronous execution.
Within a given workflow, the steps SEEM to be executed synchronously (one after the other) in most cases. It could be that workflow steps ACTUALLY execute ASYNCHRONOUSLY when possible. However, in actual practice, a multi-step workflow will do some thing, followed by some other thing (that depends on something that happened before), etc. essentially forcing the steps to be synchronous.
One does see cases that might indicate asynchronous execution within a workflow in certain situations. Here is an example:
Here’s a workflow I was creating recently where it is necessary to ensure that certain custom states are initialized (cleared out and set to null) before proceeding. (If the values are not reset to null first, certain interface problems occur – there’s just a lot of dependencies on the page):
Anyway, Steps 1 through 4 just null out the values in some custom states. Steps 5 and beyond put new values into those states and do some other stuff.
STEP 5 is a very short PAUSE step. What I found is that, without the PAUSE, things were happening too fast:
The custom state were not NULL for a long enough time for various interface elements that depend on those states to update themselves. The question is: Is it just that they were NULL for a very short time?.. or is it that they NEVER get set to null due to (what would usually be very smart) Bubble behavior.
Why was this? There are several possible/likely explanations:
- “Synchronous but too fast” explanation: Steps 1-4 do not take an appreciable amount of time to complete and so the values (while they may have gotten set to NULL very very momentarily), get more-or-less immediately overwritten. If that’s the case, the steps in the workflow ARE being executed synchronously, but it’s just too dang fast for certain other elements (which do things “Only When…” these custom states update).
- “Asynchronous” explanation: Steps 1-4 and later steps 6-8 might actually execute ASYNCHRONOUSLY, because none of those steps explicitly depend on each other. If that’s the case, those actions are being fired off not exactly simultaneously, but VERY VERY quickly and so (for example) Step 1 and Step 6 (which both make changes to the same custom state) are kind of in a race. Could be that Step 1 doesn’t even get a chance to complete.
- “Optimizations” explanation: It is possible this behavior is NOT due to the synchronous/asynchronous behavior of workflow steps. It could be there is an optimization in Bubble that sees that Step 1 and Step 6 LOOK LIKE they are redundant. (A value gets set for “Start Date” in Step 1, but nothing in the workflow is done with that value. The same value is then set again to some different value in later Step 6.) So it could be that Bubble just is just filtering out apparent stupidity (Step 1) and ONLY executing Step 6 as it SEEMS (to the workflow). This is a completely rational optimization to make and it probably saves tons of time in poorly written workflows.
Whatever the reason, by adding Step 5 (the pause), I’ve forced the workflow to both work a lil’ slower AND forced a measure of synchronous behavior (if indeed asynchronous execution of anything is going on here). Step 4 MUST complete before we take a very short pause. Step 6 can only start AFTER the pause is finished.
So, either way, it fixes the problem.
OK, so that’s a kind of interesting example, eh?
So, it’s not 100% clear to me when and how INDIVIDUAL STEPS within a workflow might executed asynchronously (or whether they ever do at all). However, when a Custom Workflow is kicked off, that definitely creates asynchronous function activity.
(This is a good thing.)
Didn’t mean to scare you or anything. Point is: just like when doing things in node.js, you’ll sometimes run into funny issues that might arise related to synchronous/asynchronous behavior.