Chris is a developer at Shopify and has contributed heavily to the API and Point of Sale app. When not developing software he spends much of his time petting kitties, brewing beer and playing boardgames.
So you have a successful application and want to help your users take your data and use it to do crazy stuff. Building an API is always a great thing to do, but now you have a new problem, aggressive polling. Your users want to have the most up to date information and it's costing you.
You want to still provide your API developers a way to get the data they need but in a way that doesn't require them to ask you for it. Instead let them subscribe to relevant changes that happens to your data.
This talk is targeted towards developers who want to make their application data available to 3rd parties such as their own users. When it comes to implementing a webhook API where do you start, what kinds of state changes do I think would be relevant to my users and how do I manage sending this data out?
Once webhooks have been registered it is now in the developers hands to responsibly inform these new consumers. As with all things in the wild, there is chaos and it's to be expected. Failure is a common case and handling that in such a way that gives your consumers chances to recover is a must.
Using webhooks is somewhat of a best of both worlds situation for users and developers. When allowing users to poll your applications you are adding another vector for resource starvation and load. A request for the 50 newest widgets every sixty seconds when nothing has changed is a waste of resources that could be better used elsewhere.
The application I work on day to day supports webhooks and I've maintained parts of the system as well as written a number of applications using the API that were heavily dependent webhooks.
Unfortunately, I have never given this talk