I use DB triggers a lot. I love them, they are possibly my favorite Bubble feature.
I’ve learned there are (at least) two main ways to implement them:
- All DB triggers in one backend workflow, with the conditions set on the workflow steps. For example: this is more like a folder of workflows for any DB triggers related to Users. Each one of these steps has its own unique set of
only whencondition (e.g.
when user before change is empty and user now is not emptyto store new users in my Airtable backup DB).
- A parent-level workflow DB trigger with its own conditions. For example the one below, where all steps inside of this workflow trigger only run when the
only whencondition is met.
It seems to me that option 1 has a big benefit of making it easier to keep your app organized. Having all
user related DB triggers in one location makes life easier (I have an equivalent one for 5-8 DB types).
What I’m wondering about is whether there is a performance and/or reliability tradeoff I’m making by implementing it this way. Does the fact that every change related to a user has to check through all of these steps come at some cost?
I’m primarily concerned with reliability over performance. Reliability because if a change doesn’t get handled properly, it could cause severe and un-debuggable consequences. Performance because these are on the backend and I’m nowhere near any of my capacity constraints as yet!