Does workflow actions happening on client level and not db level take up server units?

My app has a lot of actions happening on the front end level due to a lot of interactions and complex UI, will this affect my unit capacity allowed to my plan? Its not even fetching any data from db, its only setting custom states and closing open windows and opening other windows if other window is open etc, like if I want to open window one then it check if window 2, 3, 4, 5 is open or not and if it is then it closes that and opens 1 and so on. A ton of such micro level UI based actions are happening, im concerned if this will take up my workflow units or not.

Bubble support explained to me the costs associated with an app remain mostly on storage which can add up but only recognizes photos and files are large components of that. Having lots of database records doesn’t really have a significant impact to worry about having a lot of records of just stored text or numbers.

I never inquired about the capacity units, except they do have a pretty straightforward pricing model for adding new units.

In my understanding capacity is affected by things like how many actions are taking place, how long they take to process and total number of users on the site. With that being said, my assumption is that having an overly complex app in the amount of workflows required to operate your UX or UI will affect your capacity as it would take up some to perform the workflows.

Best practices in my opinion would be to minimize workflows. One way to do that is consider how you could use conditionals on elements to make changes in the UI…some examples include:

  1. Hiding elements by making them not visible based on conditions instead of using workflows to “hide element”

  2. Change a button element. You could have one button that changes its look based on conditions met and use those same conditions to create your workflows

There are other examples but you would know more about what workflows you have that on your app.

This specifically can be taken care of with conditionals on the windows themselves.

2 Likes

Stuff you do entirely client-side has no impact on app capacity. (Save for the actual serving of the page, of course.)

Would this be why all of your awesome plugins are working client-side?

1 Like

Yes and no, @boston85719. CG Pro is of course an interface element, so there can’t be a backend version of that, really. But of course, its Utility functions would be useful in Server-Side Actions. In fact, a lot of CG Pro actually started as SSAs.

I wasn’t excited about Bubble plugins very much until SSAs were introduced. What I originally desired to do was have lots of neat little SSAs that do various computations that we don’t have access to in Bubble operators. But the problem with that is that SSAs have a significant spin-up time. (All function-as-a-service types of things take some time to activate, but it’s pretty pronounced in Bubble and so this idea is sort of a non-starter for many use cases.)

So, I’ve only released SSAs that are intended for use in backend workflows (List Popper & Friends), not so much for returning values to an on-page workflow.

As I said, many of the utility functions in CG Pro and also in List Shifter would be really great as SSAs and I’m (slowwwwly) working on a version of LS’s PROCESS List action as an SSA as there are many things it can do that you can’t do right now in a backend workflow.

What a lot of us plugin devs want is the last couple of missing pieces to the Bubble API: Specifically, we could really use a change to Client-Side Actions that allows them to return values to the workflow, just like SSAs do (it seems weird this hasn’t been added yet). Also, it would be great to have an API to Bubble’s operators so that we could build new :operators to use in expressions (though that one may be expecting too much).