耐用的功能配方—简化Webhooks

处理Webhooks是后端开发中非常常见的模式。 您调用第三方API，该API立即成功返回。 然后，第三方会做一些漂亮的事情，例如发送消息或使用神经网络。 完成后，它将使用结果调用您的 API。

这是一个非常简单的模式，在纸面上很有道理。 但是在实践中它可能会变得复杂。 调用API后，您将完全失去状态。 服务调用您的Webhook时，您需要弄清楚它在谈论哪个实体。 然后，您需要在调用API之前重新创建它所处的状态。 通常，这涉及许多对数据库的调用，以重新创建您几秒钟前的内容。

这些年来，我已经建立了无数的Webhook处理程序。 我觉得我已经尽可能地优化了Webhook模式。 然后，我使用Azure耐用功能构建了一个。

如果您不熟悉耐用功能，请参阅我的初步印象或Microsoft 概述 。 基本上，您可以在代码中定义工作流程，同时享受无服务器的好处。

耐用的功能网钩

对于Webhooks，我们将使用人工交互模式。 此模式涉及：

• 执行一些动作
• 等待任意时间以引发某些外部事件（通常是人类）。
• 继续执行。

在这种情况下，外部事件将是一个webhook。 此食谱将涉及使用流行的Twilio服务发送SMS消息。 发送消息后，Twilio可以回复传递状态。 例如，如果消息发送失败，您可能需要执行一些业务逻辑。

我已经针对许多用例以多种语言构建了Twilio处理程序。 但是耐用的功能使它最简单。 通常情况如下：

我已经获得了有关我要向其发送消息的人的各种信息。 我发送邮件，记下Twilio给我的唯一邮件ID，仅此而已。 一切都消失了。 现在，我等待。

一段时间后（通常在几秒钟内），Twilio用唯一的消息ID命中了我的API。 这通常在应用程序的完全独立的部分中。 我使用ID查找消息，现在，我必须重新创建发送到Twilio之前的所有内容。 但是我就拥有它！ 看起来似乎不多，但从规模上看，所有这些返回到数据存储的旅程确实加起来了。

在“持久功能”中，Webhook逻辑在发送消息后一行发生。 让我们看看它是如何工作的。

进行设定

我将在Mac上运行VS Code，但这在任何OS上都可以使用。 我们将首先使用VS Code中的Azure Functions扩展在一个空目录中创建一个新的C＃函数项目。

然后，我们将需要一些软件包。 运行这些命令以获取耐用功能，Azure表存储和Twilio的扩展。

dotnet add package Microsoft.Azure.WebJobs.Extensions.DurableTask --version 1.6.2
dotnet add package Microsoft.Azure.WebJobs.Extensions.Storage --version 3.0.1
dotnet add package Microsoft.Azure.WebJobs.Extensions.Twilio --version 3.0.0

创建一个Models目录并在其中创建名为MessageInput.cs文件。 这将包含发送消息所需的属性：

发起人

我们需要某种方式来开始发送消息。 我们将使用HTTP触发器。 如果您不熟悉耐用功能，则可以忽略功能参数。

我们读取主体（作为我们之前创建的MessageInput对象），并将其传递给协调器以启动工作流程。 然后，我们返回编排状态。 而已！ 现在我们需要创建一个协调器。

编排

这就是真正的魔术发生的地方。 发送消息并获得响应的整个工作流以五行代码完成。

每个业务流程都有唯一的ID。 通常应该将此ID保密，因此我们将创建一个将业务流程ID映射到唯一ID的映射。 我们将唯一的ID发送给第三方，当他们将其返回给我们时，我们将使用它来查找业务流程ID。

我们发送消息，然后调用WaitForExternalEvent 。 这将无限期暂停业务流程，直到触发TwilioCallback事件为止。 至此，我们将拥有状态并可以继续我们的业务逻辑。

活动

创建映射

我们将使用Azure表存储（无论如何都使用持久功能）来保存映射。 Azure函数支持表绑定 ，该表绑定使您可以用很少的代码将数据拉出数据库。

我们需要一个类来保存映射：

表存储需要PartitionKey和RowKey 。 我们将保存OrchestrationId并使用RowKey将其发送到Twilio，并再次找到我们的业务流程。

此函数只是将映射保存到表存储中，并返回RowKey供以后使用。 我们可以使用表绑定来指定我们对函数参数感兴趣的表。

发送信息

Azure函数还支持Twilio Binding ，该发送带有少量代码的SMS消息。 在这里，我们创建一个CreateMessageOptions对象，并用输入的数字填充它。

StatusCallback ，是Twilio会点击以提供消息状态的URL。 我们在URL中包含RowKey ，以查找我们的映射。 接下来，我们将创建该路线。

Webhook处理程序

最后要做的是在Twilio响应状态时响应我们的API。 当然，这只是另一个HTTP触发的功能。 函数参数与上一个HTTP函数没有太大不同。

唯一的区别是它使用表绑定来查找Twilio传回的ID。 这将返回带有业务流程ID的记录，这意味着我们现在可以向该业务流程引发一个事件。

如果您还记得，协调器当前正在等待TwilioCallback事件触发，因此让我们不再等待它！ 我们通过在状态和业务流程可以恢复正确离开的地方。

注意：Azure函数当前不支持x-www-form-urlencoded响应，这是Twilio提供的。 ParseForm 为我们处理此问题。 有关 详细信息， 请参见 完整代码 。

结论

而已！ 五个功能，用于发送消息和处理回调。 最重要的是，我们可以拿起正确的 ，我们离开之前，我们开始等待网络挂接。 不再有重复的行程返回数据库。 这是我经历过的最简单的实现Webhook的方式。

查看完整的代码或上面的视频以获取完整的详细信息！

From: https://hackernoon.com/durable-function-recipe-webhooks-made-easy-4878b1972417