We’re growing! Come build the webhook infrastructure that developers love with us. Visit Careers
Weavik is a software development agency located in Waterloo, Ontario, that helps internationally renowned brands turn their business ideas into successful projects. Weavik helps companies such as Labbatt realize software-led innovations, and as an agency they value products that are scalable and fun to use.
Chris is a senior developer at Weavik, and the tech lead for Labatt projects. As the tech lead, his role is to make sure that he is delivering on his project's mandates while respecting the requirements, budget and timeline. On top of that, his personal objective is to add a layer of observability and transparency of data to improve development and troubleshooting workflows. Recently, Chris discovered Hookdeck, and took some time to talk to us about the ways it has improved his workflow.
As part of due diligence, Chris is aware that when dealing with webhooks it is important to have a queuing system sitting in front of his server. Even though Chris’s throughput volume is low, he was able to foresee issues related to server downtime that would cause losing webhooks. Of course, losing webhooks is not an option.
Luckily Chris has heaps of experience working with RabbitMQ. He estimated that it would take him 1 week to work on setting up the queues, and another week to work on the retry mechanism of the system. Unfortunately for him, that two weeks does not exist in his project timeline, as his budget is not very accommodating to building infrastructure.
When working with webhooks, Chris is familiar with ngrok and the set of challenges it comes with. For instance, every time he wants to restart his environments, he has to update the URL. He also finds it difficult to collaborate with teammates when using ngrok, because he receives the webhooks his teammates are working on on his local server.
With ngrok, I have to switch to a new URL before doing anything. It adds time and energy that I don’t really have to spare.
Chris has a logging and recovery setup for production. However, it isn’t tailored to webhooks issues, so when it comes to webhooks the workflow becomes tedious. Currently, every time there is an error, Chris must go through these steps:
Even after logging into the database, depending on the provider, Chris may need to have a different workflow to figure out how to fix the failed webhooks. Can they be fired again by the provider? Does he have to create a reconciliation script? These are all concerns he faces while troubleshooting without a setup tailored to webhooks.
If he's unlucky and experiences a server downtime, then an alert would not be triggered and the events wouldn't be recorded in to the database.
Chris heard about Hookdeck through a friend. His first reaction was "that’s something I thought about creating internally!” He wanted a headless queue to have observability of his webhooks, so Hookdeck ticked all his boxes for development workflow. Now, he can avoid ngrok and have the level of visibility he wants.
Chris dipped his toes into our services by taking advantage of Hookdeck's permanent URL in his development workflows.
Hookdeck has been great for development! If you don't change the URL often because of ngrok, you can forget how to set it up, but with Hookdeck it's always the same one line. There's no context switching regardless of the source and I didn't need to learn how to rework the environment.
Chris doesn't give his stamp of approval easily for SaaS products; he is a big believer in open source software because it helps him avoid getting tied down to a product. But after using Hookdeck in development, he decided to gradually test and place Hookdeck in front of his webhooks in production, starting with the least critical. The last webhook he would consider putting on Hookdeck was Shopify because it is the line of the project, and he didn't want to run the risk of losing a single order. However, one day after experiencing an incident involving Shopify, Chris noticed Hookdeck delivering webhooks efficiently for his other sources. He decided that he was ready to take the leap and set up his Shopify webhooks in production on Hookdeck, and he hasn’t looked back!
Observability completely changed his troubleshooting workflow.
The fact that I receive notifications when something fails and I can inspect the exact webhooks that failed is a big deal.
With Hookdeck, when there's an error, Chris :
In comparison to his previous troubleshooting system, Chris now has much more visibility and control.
By deciding to go with Hookdeck instead of building his own queuing system, Chris was able to save over 80 hours of work setting up the infrastructure (and many more hours down the line having to maintain it). The time he saved with Hookdeck allowed him to fit the project development within his allotted budget.
When it comes to the benefits of using Hookdeck's CLI, Chris shared that it has been a big time saver. Set up time has gone from an hour to just 5 minutes every time he or his teammates have to do development work. On top of that, up to 2 hours are saved each time there's a new developer to onboard on a project.
Things rarely goes as planned. When code is shipped in production, edge cases can happen and the reality is that there's an element of unpredictability because webhooks are sent by a third party. Based on previous outages and their scale, Chris had to spend time investigating and troubleshooting. He estimates that smaller issues aren't a big time commitment, but also remembers bigger issues that would take him a few days of works to fix before Hookdeck, which takes 10 minutes.
Chris considers Hookdeck an invaluable part of his stack when working with webhooks. The amount of time saved not having to manage a queueing infrastructure, on top of the observability he now has, has allowed him to take control of his budget and maximize his productivity!
