Early last year I began to move a lot of my workflows to the backend to improve performance. Then after the WU debacle there was talk of keeping workflows client side (to reduce WU consumption), so I left the workflows as they were.
The plan is to grow enough soon to move to a dedicated server where WU’s aren’t an issue.
So in your experience, for performance, am I best moving as much as possible to the backend so the app appears quicker?
What are the risks of moving almost everything to backend and are there particular workflows you’d recommend keeping client side?
The other advantage of backend workflows is more modularity as can be scheduled from anywhere (for example, have one ‘signup’ workflow that runs all of the account creation logic, and you can use the same workflow on the signup page, the team invite page, and the super admin page without any additional work).
I generally shoot for backend workflows for anything that will be reused or is more complex than a few actions.
Remember what doing it in the backend means. Doing it in the front end means ‘let’s wait until this is done before doing the next thing’. Doing it in the backend means ‘let’s do something now whilst this happens in the background’. The actual logic takes more or less the same amount of time. If you create 10 things in 10 sequential actions (hypothetically), that’ll run in about the same time in the front-end as it will in the backend. It’s just that in the front-end, if that’s followed by a go to page action, it won’t go to page until all 10 have been created.
Thanks @georgecollier, this really helps me. With the backend workflows do you add a delay as to when they trigger and if so how long between each being triggered?
Security: everything that needs some level of security should be done in backend. Everything done in frontend is visible and can be manipulated from the browser.
Reliability: what’s done from the frontend can be interupted mid-flow for any reason (internet crash amongst other reasons). Do critical flows in the backend.
Great thanks @bonjour_17 I’ll keep this in mind when changing workflows too!
Brilliant thanks @georgecollier, I’ll add delay for looped workflows but wasn’t sure if I’d overwhelm the server if I fired them all off at the same time
I think looped workflows or ‘recursive workflows’ are dead. Seems like moving forward things should be backend workflows on a list with a method for ‘knowing’ when the list is complete and how to trigger other workflows afterward so as to do things that might have been possibly affected by race conditions.
At least for me now, I am planning on not using recursive workflows as it would seem Bubble has made it so backend workflows on a list are reliable, faster than recursive workflows and FAR LESS COSTLY in terms of WUs…think about the WU cost of scheduling a backend workflow and the costs of carrying the parameter list of things
Biggest risk and inevitability is paying more in WU consumption than necessary.
I wish there was an easy way to flag a backend workflow as being complete. Right now when I generate a list of things using Backend, I’m generating a random code I place on the newly created items, and on the frontend I have a state doing a count on the number of items in the DB with that code, and when that matches the number of items in my Repeating Group I used to create the items in the backend, that’s what triggers the frontend conditions, sets my list, goes to new thing, etc. I know not every use-case would be able to operate like this, which is why I’d love some native flags tied to that backend processing…
There are easier ways than that. If you have not yet, I’d suggest reading through the thread linked as it covers some different approaches to understanding when the backend workflows have completed. Previously I always used recursive workflows, not just because schedule backend on a list was unreliable, but also, I was under the assumption there was no way to know when that schedule on a list finished, but the comments in the thread shed light on approaches to be able to do just that.
When I would do a recursive workflow and needed to know when everything was finished so that I could do something on the front end after the processing was completed on the backend, I would have a data type called ‘processor’ with a data field called ‘complete’ of type yes/no. When I would schedule the backend workflow (recursive) I would also create a ‘processor’ (whose default value for field complete is no), then I would schedule a custom trigger when data changes to look at that newly created processor. The custom trigger would then do whatever I needed to have done on the front end when the processing in the backend was complete.
Yes, would be a fantastic new feature to allow us to ‘trigger a custom trigger when result of step 1 is complete’ whereby we have on front end already custom triggers, and the result of step 1 in my example would be the schedule of a backend workflow on a list. This should not be an impossible task for Bubble to implement.
You can have a ‘Backend Status’ data type. You’ll need the normal fields that link it to the User/Company/Account/whatever for privacy rules, and then have a ‘complete’ (yes/no) field, or possibly a Status option set.
Create a Backend Status before scheduling the backend workflow. Then, watch Backend Status for changes (Trigger custom event when data changes is the action). Pass the Backend Status to the scheduled workflow. When the workflows are complete, make changes to the Backend Status to mark it as complete in the way you choose. This will result in a trigger on the front-end that you can use to do things after the data processing is done.
