Moving workflow to backend using API workflow to avoid capacity issues

I would like to move some of my workflows to backend workflows, as I heard that this will improve the app performance and to avoid capacity issues.

first, is this true? will using the API workflow help in the capacity issues?

second, if this true, then at what date should this workflow should be scheduled at?
current date-time? like this? won’t this conflict with other APIs workflow or something?

3e5d250857ea35411d98d45a8c10ac0172110dda_2_570x500

Did you find an answer? :slightly_smiling_face: :computer:

well yes after experimenting, this the correct way to do.
And yes this will help in performance too since API WFs will be queued.

Ohh, okay. Thanks

I have a “make changes to list of things” for 1000-2000 items, but it only runs once or twice per user. Do you recommend doing a backend workflow for this?

Of course, I would definitely use backend workflow for this

Okay, thanks

Backend workflows are definitely better for changing a large list of things, but they are far more intensive when it comes to capacity. We’ve had even simple workflows with one workflow action that spiked capacity to 20 or 30%, whereas on the frontend it used essentially zero capacity. Some of our heavier backend workflows are spiking capacity to 90%+, but they are scheduled events that you can’t run on the frontend.

1 Like

Makes sense @samnichols . The title of this post implies that backend workflows use less Bubble capacity, but it’s actually the opposite. A regular (frontend) workflow can use the user’s browser for some stuff, so it requires less Bubble capacity. A backend workflow relies 100% on Bubble capacity. And for this same reason, a backend workflow can improve performance at the user level, since it frees up frontend browser capacity.