New Year Updates to ASP.NET WebHooks Preview

We just released a new update of ASP.NET WebHooks with a couple of interesting new features on the WebHooks sender side – that is, when you want to send WebHooks to others when some event happens – including:

Sending Events to All Users

In addition to sending events in the form of WebHooks to individual users, it is now possible to send WebHooks to all users who have registered for a particular event. We now expose the method NotifyAllAsync in the same places where you could use NotifyAsync to send notifications to all active registered WebHooks.

Also, you can use a predicate as a filter if you want to control which users get the WebHook notification. For example, in the below illustration, Receiver 2 and 5 don’t get this particular event due to the predicate.

Using NotifyAllAsync is very similar to using NotifyAsync and it is available in the same places. Assuming you have a project already set up to support WebHooks as described in the blog entry Sending WebHooks with ASP.NET WebHooks Preview or using this sample, here’s how you can use NotifyAllAsync in an MVC controller:

Sending WebHooks: Scaling Out and Load Balancing

We have introduced a new IWebHookSender abstraction which allows you to scale-out and load-balance the act of sending out WebHooks. That is, instead of having the Web server directly sending out WebHooks, it is now possible to have an architecture like this allowing you to both persist WebHooks on the sender side and to scale up and out as you want:

On the sender side, you now need a process that can dequeue messages from the Azure Storage Queue and send them out to the targeted WebHook recipients. This can be a simple command line program (like this sample):

The two highlighted lines are the key ones – the first creates the AzureWebHookDequeueManager using the given connection string pointing to the queue. The second line starts an event loop returning a Task that you can cancel when you are done. The AzureWebHookDequeueManager will periodically poll for new messages in the queue and send them out as WebHooks.

If the WebHook requests either succeed or return HTTP status code 410 Gone, then we consider the message delivered and delete it from the queue. Otherwise we leave it in the queue ensuring that it will get another chance of being sent out after a couple of minutes. After 3 attempts we give up and delete the message from the queue regardless. For more information about Azure Storage Queues, please see the blog How to use Queue storage from .NET.

Like for the sender side, we can provide the Azure Storage connection string in the config file, for example:

Join the conversation

I know you've said it before, but WebHooks are not SignalR. Although the more you do with it, the more it looks that way. 😛

You really should consider prefacing each webhooks post with an obvious link to a resource that does a good job differentiating the different technologies (along with REST, web services) for people like me who are still dazed (in a good way) with all the new information coming out.

In any case, Happy New Year Web Team. 🙂 Let's make 2016 count big time.