slack-api - 用于将 Slack api 与 Multi-Tenancy 筒仓模型部署集成的应用程序架构

Question

我正在开发一个专门用于与 Slack 等消息平台集成的应用程序，但也有一个 Web 应用程序。整个堆栈在 AWS 中，利用无服务器模型，因此每个客户都将拥有一个完全孤立的架构，在 slack 组件之外，该组件必须具有共享 API 以根据他们的应用程序要求与 Slack 集成。
到目前为止，我提出的处理它的最佳方法是使用 DynamoDB 用户表，其中所有 slack ID 都绑定(bind)到 cognito_id/email，并且来自 Slack 的任何事件都会被丰富，然后传递给特定的客户 lambda 函数，但我在那里看到一长串令人头疼的维护问题。
人们是如何处理这件事的？

Answer 1

一般来说，将 Slack 集成到您的 Multi-Tenancy 应用程序中，其中您的每个租户都可以带来自己的 Slack 工作区，这有一些复杂性。

授权和凭证管理 .作为应用程序的开发人员，您将在 Slack 市场中注册一个 Slack 应用程序。该应用程序将在 asking your users to authorize access to their Slack workspaces 时使用.在您的用户获得授权访问后，您将获得他们 Slack 工作区的访问 token ，允许您调用 Slack API 向他们发送消息等，具体取决于您请求的范围。您将需要存储这些凭证以备后用，在您的应用程序中关闭客户 ID 的概念。

身份映射 .如果您正在使用 Slack eventing ，您的单例 Slack 应用程序将从您客户的任何和所有工作区接收 Slack 事件。您将需要查看事件负载并根据负载中的数据反向查找您自己的客户 ID。此过程可以基于 Slack 工作区 ID、最初在该工作区中授权您的应用程序的用户的 Slack ID，或生成该事件的用户(该工作区的成员)。一旦您确定了您的应用程序客户的客户 ID，您就可以以特定于客户的方式处理该事件(例如在您的情况下将其传递给适当的 Lambda)。

怪癖 .特别是 Slack 对事件和 Slash 命令处理有一些特定要求 - 您的应用程序必须 respond with 3 seconds的接收请求。如果您预见更长的处理时间，则必须分两个阶段完成 - 首先，您快速同步响应以确认收到，然后花更多时间异步处理偶数。

为了解决上面的 1 和 2，您需要使用一些存储机制，允许从您自己的客户 ID 或 Slack 身份开始双向查找身份。 DynamoDB或 Aurora如果您在 AWS 中运行，则是合理的选择。
当 implementing an inbound Slack integration in your app 时，还有更多的考虑因素。 ，包括节流、重试等。