Destinations: Webhook vs. Service Bus. Which one should you choose?

It’s been about a year since we introduced the concept of Destinations in Enterspeed. Back then, webhook was the very first Destination we added. The Webhook Destination is a very easy way of setting up communication between two applications and that brings a lot of opportunities.

A couple of months ago, we introduced Azure Service Bus as Destination too. The Azure Service Bus is also used for communication between applications and can be applied to many of the same use cases as the webhook.

So, what is the difference between the webhook and the Azure Service Bus Destination, and when should you use one rather than the other?

Let’s take a look at the differences so you can figure out when to use webhook and when to use Azure service Bus.

Webhook

Webhooks are HTTP requests that enables communication from one application to another in real-time – and since they are just HTTP requests, they are typically easy to consume.

A webhook request is usually event based, meaning that when something happens in one application it triggers a webhook, which allows another application to react on the event. On a website, for instance, you might want to automatically create a new user in your CRM system whenever someone signs up, or maybe you want to index a newly created content page in an external search index – you can do both by sending a webhook request.

In Enterspeed, the Webhook Destination sends an HTTP request whenever a view is created, updated, or deleted. On a Webhook Destination you configure the URL you want the request to call, and in a Enterspeed schema, you call the Destination. This allows you to react on these events for specific views and keep your applications in sync.

Even though webhooks are easy to consume and have many useful use cases, they also have some downsides.

As the webhook uses HTTP requests to communicate, there is a dependency between the applications. The sender needs to know the URL of the receiver system and both applications need to be online at the same time for the communication to work. If the receiver is offline when a webhook request is made, the request simply fails, and the message is lost (unless you implement some retry logic or queue system).

You should also be aware of the expected load on the receiving application. Let’s imagine a ticket office. They sell tickets to an upcoming concert and prior to the ticket release, there is almost no traffic on the site. Once the tickets are released, however, the site gets a lot of traffic, and they sell a whole heap of tickets in a short period of time.

Every time a ticket is sold, a webhook request is made to another application that sends out the tickets via email. This means that the email system suddenly receives a lot of requests, and it might not be able to keep up – and thus it starts to fail.

If you use a webhook, this is something you need to be aware of. Maybe you are confident that the number of webhook requests are limited, or maybe you are able to scale the receiver application. If not, you can implement your own queue system and flatten the number of requests over a longer period.

Pros

• Enables communication across applications
• Easy to use
• Integrates naturally with systems like Zapier
• Doesn’t require new infrastructure

Cons

• Higher dependency between applications
• Potential message loss if receiver is not responding

Azure Service bus

The Azure Service Bus is a message broker with message queues and publish-subscribe topics, and just like webhooks, the Service Bus enables communication across applications. They facilitate the communication quite differently, though.

With a Service Bus, the message that’s triggered by the first application is stored in a queue and not delivered directly to the second application. This means that the receiver doesn’t have to be online when the message is sent. The message is simply stored in the queue until the receiver is ready to read the message, which makes the communication more resilient and decouples the two applications.

Let’s take a look at the ticket system example again. But this time we replace the webhook with a Service Bus.

When the ticket office starts to sell a lot of tickets, every sold ticket produces a message in the Service Bus. But instead of sending a lot of real-time requests to the email system, the email system simply reads the messages, one at a time, in its own pace. Now this might take a bit longer, but the email system doesn’t fail because it can’t keep up with all the requests.

Besides the queue system, the Service Bus also offers you topics that provide a publish-subscribe mechanism. Thus, you can publish a single message and have multiple subscribers for that message. This is very useful if multiple applications need to be notified about the same event.

In Enterspeed, the Service Bus Destination sends a message whenever a view is created, updated, or deleted in the schemas you have defined. When setting up the Service Bus Destination, you simply type your connection string and the name of the queue or topic you want the messages to be sent to. This allows you to react on these events and keep your systems in sync.

Pros

• Enables communication across applications
• Reliable communication
• Decouples applications

Cons

• Requires new infrastructure

Summary

As with many other things, there is no simple rule to define when to use Webhook or Service Bus. It all depends on how much and what kind of traffic you expect for your applications. But there are some general rules of thumb:

In general, the Service Bus is a more reliable communication between applications, and especially if you either expect the receiver application to be offline at some point or to experience peak periods where the receiver might not be able to keep up with the number of requests.

However, if you’re confident that you can handle your webhook requests and already have a web API that you can easily send your webhook requests to, it might be a suitable solution that doesn’t require any new infrastructure.