DB Change Action > Wappler Version

Hey all,

Bubble released what I considered a really excellent feature prior to me moving over to Wappler. Essentially when a change happens to a record, or a specific field within a record - you could setup server site workflows based on that change, this was super useful.

Do we have a similar equivalent already within Wappler?

Like a trigger? Zendesk for example, if you have ever used it, has some awesome triggers! As far as I know with Wappler (within Wappler itself, native, no hacks) this is not yet possible…? Maybe I stand to be corrected there though, and in no doubt there are probably plans for this…? We have used Zapier in the past to do precisely this type of thing. It, unfortunately, is a further cost to the stack but a small one for all its uses… Would be awesome to see some of this functionality incorporated in to Wappler that is for sure!

https://zapier.com/

Essentially yeah, it’s the trigger that fires any of the backend workflows we want to run from it in Bubble.

We use Zapier / Integromat exensively for various automations - but having this kind of triggering ability to then run entirely server side actions and workflows would be brilliant.

1 Like

It would be an epic addition! Maybe worth a Feature Request? I’d vote for it in a heart-beat. I’m not a Bubble user so am not familiar with it, but as a feature within Wappler itself, outside of Bubble, as I said, would be epic.

:wink:

Should be easy to implement.

You just need a trigger at DB level and then hit an API endpoint on your app to perform some action.

It has performance issues to take into account. The same as Bubble’s implementation which most probably uses the same approach.

We are thinking to implement more server side events indeed and automatically run actions upon their trigger.

The first candidate for this will be time scheduling in NodeJS. So you can run actions automatically at specific time. Much what you do now with cron jobs in PHP.

Database triggers however are very much database dependent and difficult to implement. Also using such triggers is very error prone to your business logic. Changes get executed that you don’t know why and from where. So very difficult to debug.

Usually it is easier just to centralize your database updates in the right server connect actions and then within the same actions, after the database update step, do your extra actions. This will preserve your business logic and have it all in one central place and not scatter it all over the place.

We do this a lot, the problem is forgetting to update them occasionally… Maybe a trigger builder aside the DB Manager could be a solution? Hitting that API endpoint is the leap for us…

1 Like

We create a trigger table where only trigger data is sent at least this way we know what is happening and where. Dumps the trigger name that fired the action and its purpose. A little lame but allows us to keep an eye on what triggers are being hit…

I remember this library with RoR. I haven’t seen anything similar for node unfortunately.

It supported MySQL, PG and SQLite

1 Like