Automations triggered by events : What to choose between the Daemon or the webhooks?

Pipeline Integrations
, ,
1

Hi everyone!

I’m a junior Flow TD forming myself on my own.

I’m thinking about implementing automations on my projects, with a event triggering a change of status or filling directly a field for example.

I’ve done some research and I found the SIGGRAPH Developer Day 2019: Advanced Shotgun Development video from the team exploring both the daemon and the webhooks as an event manager interface.

However, I struggle a bit to understand the pros and cons of each one depending on the configuration needed by a studio or a specific project.

Could someone please explain me the main differences they implement in the production pipeline so I can chose the better option depending on the needs ?

Thank you and have a beautiful day ! :sun:

1 Like
2

Hi, glad to see TDs with a desire to learn :slight_smile:

The main disadvantage of webhooks imo is that they have to be hosted on a public endpoint, which brings with itself a bunch of issues like security, tls certificates, etc.
For an on-prem studio, the daemon is easier to deploy. It tends to be less stable, though.

Web hooks are a “nicer” interface, more clearly separated.

That said, there is pretty much no functional difference. Just a matter of setup and convenience.

By the way feel free to PM me with other questions.

1 Like
3

There is a functional difference as well, missed webhooks events (due to your endpoint being down for example) cannot be “replayed”.

The event daemon can be set to “replay” from an event log id.
Hence you can do maintenance on your Event Daemon host and then restart it to continue where it left off.

The event dameon scans the event log stream for new event logs.
The Webhooks are fired off in real time (just as events) but if your service doesn’t catch them then they are missed.

3 Likes
4

Hey Ricardo,
There’s a feature with the webhooks that allows you to re-send selected events. However I think the history only goes back a few days. I’d be curious to see if that functionality is exposed via the api.

1 Like
5

Also keep in mind that re-sending events via the webhooks page will act as-if the event happened again, thus potentially causing duplicate actions since it will trigger all webhooks that respond to that event type, not just the one you are re-sending from.

6

Yep I’m aware of that.

But indeed I think it’s only a UI feature and then again, it just wouldn’t really be preferable over the event log.

Webhooks in my mind are usefull for those services where a current notification is helpfull, like sending a slack message when my version has comments etc.

If for some reason these get missed it’s not the end of the world.

2 Likes