Support for Webhooks about hazel HOT 8 OPEN

The reason why we have chosen not to go with webhooks (like Nuts, for example) is that they simply don't scale that well:

Assuming that you have 10 instances of Hazel up and running, only one instance of those will retrieve the notice that a new release was created over the webhook. In turn, only that single instance will get the new application update.

That's why we're polling. 😊

If you want your updates to be delivered faster, you can decrease your interval to 2 minutes or so.

from hazel.

I feel that is more a problem with how this server is implemented that one inherited from the use of webhooks.

If you wanted something more scalable, then you would have a master service which receives the ping and then notifys each of the platform nodes of the update.

That being said, i respect what you have chosen, though i do consider it inefficient and perhaps a little evasive in the pursuit to a real solution to a scalability problem.

from hazel.

Talking about Now's way of scaling deployments, instances are completely separated from each other and therefore not able to determine whether or not other ones exist, where they exist and what their status is.

Since I don't think that this will change in the near future and we're basically focused on making it work perfectly on Now first, it doesn't make sense to introduce webhooks.

from hazel.

I fully understand and appreciate that, i was just stating in general independent of platform.

from hazel.

Actually we only need to run this when a certain path (let's say /refresh) is accessed. In addition, we need a new environment variable for a secret to compare with the secret contained in the payload.

The path should only be enabled if the SECRET env variable is defined, otherwise the request should be handled by the final request handler.

from hazel.

@leo indeed you do, i wasn't suggesting this blindly (there was reason behind it) 😄

The biggest reason i suggested it is if enough people started using this with multiple instances, you are basically a DDOS attack waiting to happen (it's happened before), with this, you only ever do something when needed (making it way more efficient).

from hazel.

That's not completely correct. With the interval mechanism, Hazel respects the limits of GitHub's API and that's far away from a possible DDoS attack (even when scaled to multiple instances).

What I just proposed only makes sense when Hazel is running on a single instance, so there won't be many use cases. But still, it's worth implementing.

from hazel.

@leo Ah, so it does, my apologies. Yes, it's not something everyone will use but it makes your tool more flexible to a wider array of cases.

from hazel.