News
ASP.NET WebHooks Preview 2016 Update
It's a small step, but a duet of sender-side features are enabled in this preview that allow a more nuanced way of pushing out event-driven WebHooks to users.
All has been fairly quiet on the .NET front (and other developer fronts as well) during the holidays, but there's still some incremental but important work going on in some .NET corners. Here's one: an update to ASP.NET WebHooks Preview that allows for a more nuanced way of pushing out event-driven WebHooks to users.
Before we go into the new features, how about a quick bit on what webhooks are? At their most basic, webhooks are push notifications, and ASP.NET WebHooks are the .NET version of webhooks. Microsoft Principal Architect Henrik F. Nielsen explains them in a bit more precision in an introductory post from September that they're a "lightweight HTTP pattern providing a simple pub/sub model for wiring together Web APIs and SaaS services." So, webhooks can be built mainly for users to receive webhook events, such as notifications, from any number of providers who offer them in their apps. Webhooks are also configurable on the sending end, where users or developers can specify and manage the providers (such as SalesForce or Instagram or Slack) from whom they're receiving events.
So, while the the features that were introduced at the outset of this year might seem like small steps, they're important enough for Nielsen to blog extensively about them here. What's new is the addition of two sender-side features. The first is the ability to send events to any user who has registered for an event, and this is done with the NotifyAllAsync method. The method can be filtered using a predicate so that only users filtered to receive that specified WebHook notication.
The other feature is the ability to scale out and load balance events via persistent queries. "Instead of having the Web server directly sending out WebHooks," writes Nielsen, "it is now possible to have an architecture [that allows] you to both persist WebHooks on the sender side and to scale up and out as you want." An example of the architecture is shown in this diagram on his blog.
The scale-out feature is enabled through a new iWebHookSender abstraction that simply is registered on the front end. Then on the sender side, Nielsen writes that developers would then "need a process that can dequeue messages from the Azure Storage Queue and send them out to the targeted WebHook recipients."
You can learn more about ASP.NET WebHooks at this blog and this blog as well.
About the Author
You Tell 'Em, Readers: If you've read this far, know that Michael Domingo, Visual Studio Magazine Editor in Chief, is here to serve you, dear readers, and wants to get you the information you so richly deserve. What news, content, topics, issues do you want to see covered in Visual Studio Magazine? He's listening at [email protected].