Why Webhks?

Intro

Development of any service consists of many components and some of them are much easier to do than the others which have a tendency of complicating the setup just due to their nature.

Periodic tasks

The easiest feature to build is a web page - any cheap php webhosting could help with the task all the frameworks are tailored primarily to serve these needs.

In contrast, any periodic tasks are harder to implement:

• A developer needs to be able to access cron table
• In many cases (e.g. laravel a storage is required in order to coordinate task runs and there is no interface to check the status of different tasks or the result of any of them
• Due to the fact that tasks run offline it's harder to troubleshoot them in case of problems on production (e.g. local code runs successfully, but deployed code fails

Webhks allows to solve all three pain points in one go:

• Any periodic action can be implemented as yet another http action, no additional setup is required on the server
• No additional requirements to the storage, status of every call is recorded on Webhks, easy to inspect and troubleshoot
• Since every action is just a url to trigger, troubleshooting is much easier. You can either trigger the url from the browser / via tools like curl or you can easily trigger a manual run on dabdab and check the results.

Webhooks from external services

This is a pain point familiar to any developer who interated an external service into the system. Many of the services provide a convenient functionality of webhooks when they would call a service in question in case of certain events like email delivery or a new payment.

There are many problems that stem from the fact that webhooks are actually not trivial to implement in a good way:

• External service may only allow to define one webhook which could be limiting if you use this service from multiple environments or you want to have a better granularity (e.g. email delivery webhooks should call one subsystem, email bounce webhooks should call something else).

  This limitation is not innocent since it affects the architecture of an application being built

• Many services provide zero visibility and observability on the webhooks, frequently even without retries, which means that if there was a bug in your code and webhook call failed, there is no way to get this information again or even have an easy way to check the failed webhooks or get notified about the failures (a webhook may be rare enough for error alerting to kick in)

  One of the ways to overcome this limitation is to start recording all the webhook calls in the database and implement webhook handlers as periodic tasks which has all the drawbacks mentioned before and also inflate the database size

Webhks gives a best in class support for the webhooks (automatic retries coming soon!):

• It's possible to create a url that would serve as a webhook target for an external service
• For every incoming call it's possible to define one or more urls to call with optional filtering by request contents
• All the payloads are recorded (up to certain size) as well as responses, you can always check the failed webhooks, do adjustments to your code and trigger them again