Today, we’re excited to be rolling out a behind-the-scenes improvement to the way that workflows are run. Workflows with sets of consecutive actions that update the database are going to see performance improvements of around 25% (see below).
Some context: Each Bubble app has a server, maintained by Bubble, which stores its data. When a workflow changes an app’s data, the app sends an update to the server about the new state of the database. This operation can take a significant amount of time, so we would like to minimize the amount of times it is performed.
Previously, Bubble apps made changes to their database one action at a time. For example, if an app had a workflow where the first action is “Make a new thing”, the second is “Make changes to a thing”, and the third is “Delete a thing”, then it would update the database three separate times before proceeding with the next action in the workflow.
Now, Bubble apps are a bit smarter about the way they do this: if a workflow has a set of consecutive actions that require updating the database, the app will batch them all together, send one large update to the database, and continue with the rest of the workflow. Implementing this change led to a noticeable improvement in performance.
Below is a summary of the speed gains that were observed while testing these changes. As the size of the set of consecutive actions increases, so does the size of the speedup.
This is great news @henryd , and much desired. Quick question though - if a DB action creates a cascading action on the DB, prior to another DB action with a re-scan conditional on the DB, will the new process be able to account for that?
i.e.
Action 1: Insert new object with a flag of A amongst other objects with flags in domain {A,B,C}
Action 2: IF total count of A’s >20, make a change to first 5% A’s that exist, changing them to C’s
Action 3: Do some unrelated calcs and then Delete all C’s
Obviously, it would be impossible for these three actions to fit into one composite SQL statement. Does the new Bubble engine abort a composite statement if it detects conditionals or re-scans/searches on the DB in subsequent actions?
PS, I cannot stress the positive impact to our app this intelligence brings. Thanks Bubble team.
I have similar questions as @david17 and @anon38627393… I assume the assumption is that we’re using the “result of prior workflow” steps to ensure things are run linearly, but there are various times where that is not an option.
Great question @anon38627393. In short, workflows of the type that you described above will still work under these new changes, and more generally all workflows should work exactly the same as they did before this update (and if you notice anything not working, please submit a bug report so we can put out a fix!)
I can certainly see why you would be curious about this, though. If the Bubble workflow engine wrote to the database by simply taking actions and translating them into SQL statements one by one, then we would be in trouble.
Thankfully, though, Bubble apps already send workflows to the server as a single chunk of data, so the workflow engine is able to ensure that actions that reference previous workflow actions run properly. This deployment doesn’t change the way that the server runs workflows, it just optimizes the way that updates that result from workflows are written to the database.
Hi @nicolas_dap—unfortunately, this change doesn’t affect “Make changes to a list of things” right now. However, we’re always working on workflow performance and it’s possible that we’ll be able to make improvements there in future changes.
So it sounds like the new “composite query builder” functionality is post-AST tree delivery / interpretation by engine. So a final statement-compression-check sort of thing, which is perfect. Thanks a bunch!
Hi @david17, great question! I just responded to Jesse but I figured I would respond here as well.
First, I agree that the documentation surrounding this behavior could be a lot better. We’re working on improving our manual right now, actually, so hopefully that will clear up some of the confusion surrounding API workflows.
As you said, in the workflow example you gave, B may not finish running by the time Action C is run , and as a result Action C may not be able to edit A with the result of B. Today’s changes won’t alter this behavior, because it only batches together sets of consecutive actions which are of type “Create a new thing”, “Make changes to a thing”, or “Delete a thing”. Because “Schedule API Workflow” isn’t one of these three, there’s no chain of consecutive actions of these types in the example you gave, so none of the actions here would be batched together. Thus, this kind of workflow will behave the same as before today.
