Please, I need to know.
Well, that depends.
Thanks for the response Keith,
As an example then, if I use an API workflow to delete N database entries, and then I use a Frontend Workflow to delete another N database entries, what would determine the speed of each action?
Is there documentation on what database is being run in bubble, and best practices for updating multiple database entries at the same time?
I believe they’re identical, with a few caveats.
Effectively, both workflows are triggered on the front-end but they run on the back-end. And, if you used the same action (e.g., delete N database entries) then the speed of that is primarily driven by the calculations / deleting of records on the backend.
My primary caveat, then, is that running this through the API workflow adds 1 step to the process (it goes from the page to the API to the backend) which makes it a bit slower. But, with this type of query, it’s probably a small number of milliseconds slower (i.e., nothing a user would notice). Additionally, API workflows run in the background so if your server is at 100% capacity, then workflows that are triggered on the page will take precedence over workflows run from the API. So, the API workflows would be materially slower in this scenario.
1 Like
Thanks sridharan!
That makes a lot of sense, and is very useful to know. Thanks for always being super helpful in these forums!
Nick Choi
1 Like
Hi @nchoi, what I was getting at was it depends on what the “frontend workflow” represents.
When we’re talking about modifying “N” things, we are in list-of-things land. And the limiting factor for efficiency in speed terms is how one is handling that list. There are multiple ways that we might modify a list of things… For example:
- We could use “Make changes to a list of things” – and such a workflow step could exist in an on-page workflow or in an API workflow. Execution of both steps should be roughly equivalent at the time of execution. (But keep in mind that an API workflow might be scheduled for some time in the future – at a minimum, there would be some small (perhaps infinitesimal) delay in kicking off that workflow, even if it is told to execute right now (at “Current date/time”) Is that any different from the delay between – for example – when a button is clicked and when an on-page workflow begins? That is hard to say. The difference, if any, would be slight.)
Anyway, this is clearly using some type of looping (just like when you use an “Advanced” filter Bubble is clearly iterating over the list of conditions) and it executes very fast, probably asynchonously, and you can’t mess it up.
- Instead of using “Make changes to a list of things”, we might schedule an API workflow on the list. And in that workflow, we modify just one of the things at a time. (i.e., we would “Make changes to a thing” on just that one thing… the next thing will get changed when the next iteration of the workflow executes). This is clearly going to be slower as there is a scheduling delay between each iteration of the “workflow on the list” that we cannot fully control – it will never be zero and it could be many seconds between each step, depending on capacity available to your app.
Sometimes, you can’t help but do this. For example, if the modification you need to make to each item is too complex to be expressed in the single expression that “Make changes to a list…” allows. (Like, you need to do a multi-step computation that depends on intermediate values that are themselves complex lookups or something.)
- We might use clever “hacks” in the page to get around Bubble’s current restrictions on iteration/looping/recursion (whatever you want to call those restrictions). One method is to use Toolbox JavaScript to Bubble elements to make an event loop (I keep meaning to do a video explaining what I mean by this – basically those elements can be “triggered” to send an event. So in effect, you can build looping workflows even though Bubble usually prohibits that.) OR, we might run some JavaScript in the page and loop that way. OR, we might pass some data to an external API that executes the looping and passes back the result(s).
In my experience, these techniques can be MUCH faster than “schedule an API workflow on a list”. Doing some looping in native JavaScript on the page is fastest; forcing an event loop via JS to Bubble elements is somewhat slower; and pinging an external API to do the same thing tends to come in last place.
Bubble is considering lifting the limits on recursion/looping (it’s unclear how this will work in practice, but it seems at a minimum they might lift the restriction on an API workflow calling itself). That might change things a lot (particularly if that will give some native way to loop/iterate inside a page).
The other sometimes difficult-to-work-around issue with API workflows is that it can be hard to know when they have completed. If you’re doing iterative operations in the page, you can know when they have completed. Sometimes that’s important.
Everything @sridharan.s has said here seems 100% correct, but just in case you were thinking about other ways you might accomplish an arbitrary number of repetitive actions, the above are my observations.
2 Likes
Thanks Keith for sharing your insights!
We’re just starting to open our bubble app to large numbers of customers, and so as we’re starting to think critically about how our code is currently architected, hearing your experiences is extremely valuable!
Based on yours and @sridharan.s’s feedback, I’m considering using plugins to optimize our interactions with the backend. It sounds like complex data operations may hit limitations of the bubble plugin workflow.