I just don’t understand why they don’t care. A trend I’ve noticed is that Bubble acts like a stepping stone (or training wheels) to code, it’s like they naturally incentivize people to move away from the platform after a certain amount of complexity. So the more successful the app, the more likely they are to want to move away. And simple apps have churn for different reasons (loss of interest, perceived difficulty, etc.). So what’s the long-term vision here? Just depend on Enterprise customers who don’t even realize they have a Bubble bill? The Oracle strategy?
@randomanon if you really need a solution I would suggest scheduling each workflow, and inside the workflow, scheduling the final step you want to run after all of them have been completed Only when (Do a search for the data or whatever has fully completed). You may sometimes run into race conditions so it’s imperfect
Seems like nobody does actually. I’m confused on what you’re trying to solve for. It can’t be the WUs with doing multiple writes to same thing, but most of your gripe with work around you ponder is the WUs.
I’m not sure your issue is just speed, because none of your hypothetical work arounds indicate a need for speed.
What is your issue? Speed? WUs?
His issue is speed (time from start to end of workflow), because in a backend workflow, the API calls run in sequence rather than in parallel, even when they don’t depend on each other.
Reducing the problem he faces down to its simplest form - in the backend, API calls tend to run in sequence. Okay, that limiting factor means they must run in separate workflows, and fire of another once all have completed (the mechanism of which can be debated)
That made me chuckle. Oracle oh Oracle, just let go of Javascript.
Actually I think I may have confused them with IBM. Whichever one depends on old Enterprise clients that are too lazy to switch over their mainframes to modern stacks.
Yeah, the only way to do this correctly is with DB triggers and searches which would 100% lead to astronomical WU overhead. Bubble just needs to get their heads out of their asses and deliver what they promised at 2024’s BubbleCon.
I hear you. To me it sounds like a speed issue as well. I’m just getting confused because I know @randomanon is not one to fret about WUs, but all of his retorts to suggestions to solve for the speed bemoan the WU implications.
In terms of how needing to search for something leads to astronomical WU costs, I’m unsure since it seems like the whole issue is around how to save to one database entry the results of separate api calls.
This is simple and not costly, because if you search for the unique ID of the thing, you are charged just tiny cost of 0.15 WUs for an individual data request, so even if the one database entry needs to be search 3 times using it’s unique ID it is still only 0.45 WUs, just pennies, which is peanuts for an app with money coming in.
This is fine, backend workflows run async, so if LLM Call B or C is not dependent on LLM Call A they will run async, the wait comes from the dependency on all 3 for the single database entry.
That is because there is a dependency on LLM Call B for step 1, which I think at that point breaks the async and then makes them run in sync even though the step 3 is not dependent on either step 1 or 2….so perhaps, just make step 3 step 2 and then step 2 becomes step 3 so that the two actions dependent on others are triggered as soon as their dependent predecessor is done, but at the least you’ll have LLM Call A and LLM Call C running at the same time almost.
Best approach so far for ease of implementation. Also fixes the issue with other suggested ‘solutions’. And makes it so that you can if you do put all non-dependent actions first, you are not waiting for any other to finish unless it is dependent on a previous LLM call.
Is this all needed to work with your UI client side? And why does it matter if the user knows that a backend workflow is being processed, or could some how be capable of viewing that? Also, how is your backend processing exposed, it is server side, so no relation to or exposure on a client device.
Also great suggestions.
If speed is the main issue, and WUs are an after thought, he should just build a plugin to run them in sync and have a simple set of return values to save into DB. If speed and WUs are a concern could then use something else to run the calls and return the values via backend workflow (ie: webhook). That will reduce WUs compared to the plugin since each one second of processing in backend is equal to around 0.5 WUs, so if this takes 6 seconds to complete via the plugin, it will be 3 WUs, which so far seems to be too costly for Rando to accept for running the processing he needs to run as most other suggestions that ‘lead to astronomical WU costs’ are less than 0.5 WUs if searching for same thing 3 times, or just around 4.86 if needing to create 3 new things.
Either way, my preference would be to find a simple solution and not bemoan the lack of features that make it easier or not, just work with what I have available to me.
Sometimes I think it’s funny how people primarily associate “hallucinations” with LLMs.