The biggest difference is that API workflows run on the server side, so your user could close the page, and it will still run. If the user exits in the middle of a (non API) custom event processing some heavy workflow (a change to a big list of things, for example), or before it is even triggered (if scheduled) they risk cutting it off and leaving it unfinished.
Triggering a custom event (scheduled or not) is your better option if your workflow involves element display on that specific page (e.g. showing a popup). There are tons of use cases for custom events though.
Scheduling an API workflow for current time and triggering a custom event (not scheduled) may show no difference for the user, especially if it’s a quick database action. I tend to send things to the API queue if it’s a “background process” that might take some time or if it needs to happen much later in the future after the user is likely to leave the page.
As with many things, it depends on your use case. Hope this helps.
When you refer to the Custom Events, are you referring to the ones you setup in the Page Workflow? I was referring to the ones that seem to be “server-side” custom events,which you can create them in the API Workflows page.
I was talking about triggering custom events on pages, but this brings up a good point. There are going to be instances where there will be no difference, triggering a custom event here is still happening on server side. Also, a single parameter API endpoint set to current time is going to do the same.
Maybe there’s an important technical difference that I’m not thinking of when it comes to choosing one over the other when they’re both set up to do the exact same thing, but I’ll leave that to the Bubble guys to say.
It just depends on what you’re doing. Yes, you can schedule something to happen at current time, but typically if you’re scheduling an API workflow from another API workflow, then there’s a reason for it: It needs to happen at some point later than current time, it needs to be scheduled on a list, it needs to receive multiple parameters…
One of my favorite use cases for a Custom Event is to consolidate universal actions that happen from different triggers. For example, if I have 5 API endpoints that all, at some point, need to run the same 10 actions, I’m not going to have 50 actions - I’d rather have the 10 actions under a Custom Event and simply trigger this custom event from each of the 5 endpoints. This is a scenario where the date/time isn’t the point - it’s more about keeping a clean workspace (and less room for error).
Hey @prestanalytics.info, would you mind posting this as a separate thread since this is an unrelated question to the original post here? I’ll be happy to answer as soon as I see it!