我正在尝试决定是构建逻辑应用还是 Web 应用。
它必须做一些我在 C# 中很舒服的事情：接收各种格式的消息(每天几千条)，翻译它们，进行 API 调用并转发它们。没有一个端点被广泛使用，因此开箱即用的连接器不会带来好处。有些需要自定义标头，其内容是使用哈希算法计算的。一些工作涉及将 Json 转换为 XML，反之亦然。
从我所读到的内容来看，逻辑应用的关键区别之一是无需编写任何代码。由于我们的组织实际上对代码很满意，所以感觉它实际上不会是一个好处。
我错过了什么吗？在这种情况下，逻辑应用比 Web 应用更好是否有任何令人信服的理由？
与仅编写代码相比，使用逻辑应用还有一些额外的好处，其中包括：
- 开箱即用的监控。 对于每次执行，你都可以使用复制逻辑应用设计视图的监视视图准确查看流程的每个步骤中发生的情况。
- 内置故障处理功能。逻辑应用将自动对失败情况重试调用，还允许你自定义重试策略或具有 do-till 模式的自定义重试策略。
- 开箱即用的警报。您可以配置警报以通知您故障。
- 无服务器。您不必担心大小或缩放，而是按消耗量付费。
- 更快的开发。 逻辑应用允许你更快地生成解决方案，尤其是当你认为你不必编写代码来监视逻辑应用现成的视图、警报和错误处理时。
- 易于扩展。如果已在使用逻辑应用，则只需很少的额外工作即可访问超过 125 个连接器，从而轻松增加业务价值或使其更智能。
出于以下原因，我决定远离逻辑应用：
- 它在 Azure 外部不受支持。 我们不依赖于任何其他提供程序，使用逻辑应用会打破这种独立性。
- 我不知道有多少问题使用逻辑应用很容易解决。 (似乎我将解决各种问题，如果我使用 C#，这些问题不会成为问题。 本文详细介绍了使用早期版本的逻辑应用开发简单过程时遇到的一些问题。 没有人提出比
- 我上面给出的理由(尤其是第一个)更令人信服的论据，为什么我们应该使用它，所以这将是一场赌博，几乎没有什么收获，有很多损失。
可以将逻辑应用视为业务流程协调程序 - 它采用外部功能片段，并将工作流编织在一起。
它与"编写代码"的要求无关 - 你的代码可以是任何平台上的外部函数 - 本地、AWS、Azure、Zendesk，并且所有代码都可以使用逻辑应用连接在一起。
无论选择哪个平台，你仍将面临跨领域问题，例如监视、日志记录、警报、部署等，而逻辑应用可以非常可靠地满足所有这些要求。