So, without question, the biggest and most useful enhancement that Bubble have released in recent months, is the long-awaited ability to return data from Custom events.
There are still lots of very basic things missing in Bubble though in my opinion, not least of which is having no native ability whatsoever to declare or use variables in Backend workflows. Which ultimately makes creating complex backend workflows even more complicated, and harder to maintain, than they need to be.
Of course, with page workflows we can set custom states - and these can be accessed from anywhere on the page), but there is no native equivalent of custom states for backend workflows.
Working with variables in Backend Workflows
One common workaround to this has been to use Make Changes to a Thing (or list of things) to define things for use later in the workflow. But, of course, these can only be used with Database objects so are no good for things like Option Sets, or primitive datatypes.
A more useful solution to this omission is to use a Plugin, such as List Popper, which basically lets you create and define variables, of any type, in backend workflows.
Iām a big fan of List Popper, and have used it extensively for exactly this purpose in complex applications and workflows but, unfortunately, with the new pricing model plugins such as these can be costly in WU, as well as rather slow, especially when using many of them inside a workflow.
But now, thanks to being able to return values from Custom Events, you can use a Custom Event in exactly the same way as a plugin like List Popper, for a fraction of the WU cost.
You just need to create a custom event for each type of variable you want to set, with an input and output of that type, with a single action to return the input value. That way it acts just like setting a variable.
(actually you could probably use just one custom event, with multiple inputs and outputs, instead of one for each type).
Then, in your backend workflow, anytime you need to define a variable, just trigger the relevant custom event and enter the value of the variable. Youāll be able to access it later in the workflow as the result of that step.
Testing This For Speed & WU
I wanted to test this out to see how much difference it actually makes over a plugin like List Popper, in both speed and WU cost. Presumably, triggering Custom Events in a backend workflow still incurs the cost of a server action (although looking at the logs, nothing was shown individually for this)ā¦ so I wasnāt too sure whether there would actually be much saving in WU.
So I set up a fairly simple workflow, in which 10 variables were declared (some texts, numbers, and database objects, both singular and lists), before outputting the final variable value to a database object.
I ran this 10 times for each version of the workflow.
Using Plugins
In the first version of the test I used a plugin (specifically List Popper)
The average time it took to run was 2.5 seconds (although the slowest run was nearly 8 seconds).
The WU cost was consistent across all runs, at 10.56 per run.
Using Custom Events As Variables
I then ran the same workflow, but this time using Custom Events as variables instead.
The average time it took to run was 0.8 seconds (the slowest was just over 1 second), with a consistent WU cost of 2.5 per runā¦ less than a quarter of the previous method.
Comparing to a node.js script
As a comparison, I thought Iād run the same test using a single āRun Server Scriptā action from the Toolbox plugin, to establish all the variables in a single workflow action, and output the final text.
I fully expected this to be the fastest and least WU costly method, but to my surprise it was actually slower and more costly than using Custom Events, across all 10 runs of the test.
The average time was 1.01 seconds, and the WU cost was consistent across all 10 runs, at 3.11
So, using Custom Events was clearly the best method, on both measured criteria.
In Conclusion
As things stand, there is still no specific native way to declare variables in backend workflows, but using Custom Events in the way described here does offer a solution which is much more performant and less WU costly than using plugins to achieve the same thing (at least according to my testing here).
As I mentioned above, Iāve been a big fan of List Popper over the years, and have used it extensively in many apps, but with a 75% saving on WU cost Iāll probably look to use Custom Events from here on in.
That is, of course, until Bubble release a native way to work with variables in Backend Workflows.
