This is surely the source of your overwhelming WU consumption.
So, in general, polling is bad. There’s no reason, in general, to poll something in web development. The Bubble “do every x seconds” workflow is basically just an implementation of JavaScript’s setInterval(), which allows us to call a function repeatedly after a certain amount of time. This is not for polling some backend state or for repeatedly making some API call. It should be seen as for doing something client side, like manipulating some element in the DOM. For example, imagine an on-screen clock. We might crudely animate the second hand by rotating it once per second.
But we don’t repeatedly ask some external or backend process if it’s done by repeatedly asking it “hey, are you done?” or “hey, has something changed?”. We instead wait for some active notification that something is done or something is changed. That is, web development is event driven.
And now, since Bubble charges WUs for even scheduling a backend workflow (even if that workflow might immediately abort or not fire due to conditions on that workflow), even in situations where we are not exactly polling, but doing something pretty reasonable, we have to rethink where we put our conditions (e.g., move them to the client side).
In terms of features that Bubble has that allow us to avoid polling, there are several that come to mind:
- Database trigger events (Database trigger events - Bubble Docs) can be used to run some workflow based on the creation or change to some type of Thing, based on the nature of the change to that Thing.
- Searches (the results of “Do a Search for…”) are, in the front end, live queries. If the results of a Search change in a way that would affect the items retrieved by the Search, those search results update. So, for example, if you have an RG showing results of a search for Contacts that belong to some Account in a CRM, if somebody adds a new Contact to that Account, the Contact (if the user has permission to see it) will automagically appear in that list in most cases. (So, we don’t have to poll to find out about such things.)
- When working with external systems (remote APIs or other sorts of services), we don’t have to poll them to understand if something is finished or has changed as those external systems can notify us of something important via “webhooks” (the external system can ping our app’s exposed API endpoints, aka “public API workflows”).
Anyway, just some basic ideas there about how you’re going to have to modify what you’re doing.
(Let me also stress that it’s perfectly reasonable to run some completely in-page workflow repeatedly using “do every x seconds”, but the applications for this are quite limited. Honestly, I think that workflow trigger isn’t provided in Bubble because it’s particularly useful, but just that it’s something that JavaScript can do. It’s like, “oh hey we should have setInterval().” Well, OK.)
