I would go a step further and say that it was cited as the main reason for putting so much time and energy into what would otherwise be a non-functional, purely aesthetic UI change (rather than a necessary stepping stone towards overhauling the platform).
1 Like
To be fair, it’s not just a UI change with a fresh paint of coat. The architecture of how the workflow tab works was redesigned with necessary prerequisites for performance improvements and less bugginess. Recently the whole logic that deals with the issue checker was being worked on, and nobody really mentioned it, but the editor is way faster to load on refresh now.
I’m referring to the actual UI change from left-to-right to top-to-bottom. The idea is that this was a prerequisite to bring it in line with loops, serial processing, etc. (which is technically possible left to right but gets messy very fast and needs a giant canvas like Unreal Engine).
And yes I have noticed the editor is faster and doesn’t freeze for 5 seconds like it used to every time you clicked on the workflow tab. I have mentioned it before on these forums. I’m not sure why people only mention bugs but never improvements. I notice everything.
just wanted to drop by to reinforce the notion that the team is aware. I’ve brought it up to them a few times since the new WF tab went out in May, and they have also done their own research/work around branches, loops, parallel wfs, etc.
So it’s not a case of “they forgot” or “typical half-baked bubble launch”, and more of the team having to juggle priorities in Q3 and Q4.
But 100% they are aware that this is the next evolution of the WF tab and that users want this badly. And it’s coming, just not as soon as we had all hoped.
6 Likes
Human brain hard wired to be more negative…why social media algorithms are heavy on content that gets people outraged, same for News
3 Likes
It was more of a rhetorical question but true.
Any chance we could just get a “switch” that decides if everything in the workflow runs in parallel or series?
Basically if you turn it on, all actions in that workflow immediately run unless they’re dependent on a prior action using “Result of step.”
Kind of a bandaid fix until the full thing comes out.
1 Like
Isn’t this how it works now?
Nope, actions in a backend workflow always wait for the previous actions to finish. You can test this out by stringing together a bunch of LLM calls in sequence (without using any “Result of steps”).
1 Like
If you’re referring specifically to API Connector calls, that’s true; but it’s not true of actions in general. If you need concurrency for API Connector calls, then why not use a separate API Workflow for each? Schedule them all at once, and they will execute in parallel.
Because sometimes you want the result of all three to save somewhere at once
1 Like
That can still be accomplished. It just requires a bit of creativity and a more asynchronous, event-driven approach to designing the logic.
As best I can tell, what @randomanon is requesting feature-wise seems non-trivial and isn’t anywhere on the radar or roadmap; and since the functionality is possible now, why not learn something new and expand one’s toolbox to improve the app’s UX?
2 Likes
No doubt, but it adds more complexity than need be when really we just want some API calls to run in parallel 
2 Likes
True, but it’s necessary complexity given what’s currently possible (if the value it provides outweighs the work required). One can certainly make feature requests and then hope and wait; or one can just get stuff done. (Things can always be refactored as Bubble’s feature set evolves.) 
EDIT
Who knows, maybe the Bubble team will surprise us all with such capabilities and more once the API Connector is integrated into the core platform (as mentioned in the latest update). 
1 Like
Go ahead and tell me how you would take the result of 3 asynchronous LLM calls and write them to a single thing.
Do the calls need to be triggered at same time, or are they dependent on the result of each other in order to be called? Because the idea of them being asynchronous, as in not happening at the same time, could to me, imply they could run seconds, minutes or even hours apart.
What’s the necessary parameters to get the result of saving separate api call results to the same thing?
Assume 3 calls that will be processed together in a 4th call.
Okay. I will assume also, WU consumption is of no concern, so I’ll just provide one idea off the top of my head that doesn’t cause me to have to consider WUs.
- Action that creates the data entry - which has 4 fields, like call_1, call_2, call_3, call_4
- 3 Actions after the creation to schedule 3 separate backend workflows, each of which will run their respective call, which will then save the result to the data entry created and save it to the respective field.
- A database trigger change with conditional for ‘when call_1 now is not empty and call_2 now is not empty and call_3 now is not empty’ and this will then run call_4 and subsequently save the result to the data entry into the respective field.
This of course assumes that as you’ve said, the 3 calls are asynchronous and only need to be used together in the fourth call to process them together in that fourth call and that none of the first three calls are dependent upon each other.
With this, it makes no difference if call_1 or call_2 or call_3 finish first, since the condition on the database trigger change event requires all 3 to be not empty, so which ever gets saved to the data entry last is which will be the one to trigger the final fourth call, ensuring all previous 3 calls were completed and saved to the same data entry.
Does that work for the use case or is there some other ‘parameter’ that needs to be accounted for?
3 Likes
Do you know what happens when 3 workflows try to write to 1 Thing simultaneously?
I would suspect if they are writing to the same field, maybe an issue, but if writing to 3 separate fields, maybe nothing other than writing to each field the action is supposed to write to.
I understand your point, and I expect that will not really be an issue as each backend workflow is triggered after the other, so not simultaneously and each call may have different durations to return the value.
But if you are concerned, just change approach that after trigger backend workflow 1, it’s last action is to trigger backend 2 etc. so to ensure one data entry is never written to concurrently, and yes, drag on speed/UX, but my input here is just a discussion as a thought experiment, because ultimately, I agree with you, bubble needs to put more resources into other areas besides AI and Mobile.
1 Like
Yeah, the thing is, we know there are issues with this when it comes to lists. I’m just not gonna bother doing an experiment with this and creating a convoluted mess with it’s own data type just to do something that should be native to Bubble. They are getting their lunch eaten by n8n and other “workflow” / “AI agent” builders.
Yeah, that’s what I’m doing now. But it’s functionally the same thing as having them as actions in the same workflow, so no point in multiple workflows.
