App architecture for integrating Slack api with a multi-tenant silo model deployment

user_14333677 0
Viewed 242

I'm developing an app specifically to integrate with message platforms like Slack, but there is also a web app. The whole stack is within AWS leverage a serverless model, so each customer will have a fully siloed architecture, outside of the slack component which has to have a shared API to integrate with Slack per their app requirements.

So far the best way I've come up to handle it is a DynamoDB user table with all the slack IDs tied in to a cognito_id/email, and any event that comes in from Slack gets enriched then passed to a specific customers lambda function, but I see a relatively long list of headaches in maintenance there.

How have people handled this?

slack-api
1 Answers

Generally speaking, integrating Slack into your multi-tenant application, where each of your tenants can bring their own Slack workspace, has some complexity to it.

  1. Authorization and credential management. As a developer of the application, you will register a single Slack Application in the Slack marketplace. That application will be used when asking your users to authorize access to their Slack workspaces. After your users have authorized access, you will get an access token to their Slack workspace which allows you to call Slack APIs to send messages to them etc, depending on the scopes you requested. You will need to store those credentials for later, keyed off the notion of a customer ID in your application.

  2. Identity mapping. In case you are utilizing Slack eventing, your singleton Slack application will receive Slack events from any and all of the workspaces of your customers. It will be on you to look a the event payload and reverse-lookup your own customer ID based on the data in the payload. This process can be based on the Slack workspace ID, the Slack ID of the user who originally authorized your application in that workspace, or the user who generated that event (a member of that workspace). Once you determine the customer ID of the customer of your app, you can process that event in customer-specific way (like passing it to the appropriate Lambda in your case).

  3. Quirks. Slack in particular has some specific requirements around event and Slash Command processing - your application must respond with 3 seconds of receiving the request. If you foresee longer processing, it must be done in two stages - first, you quickly respond synchronously to acknowledge the receipt, then take more time to process the even asynchronously.

To solve 1 & 2 above, you will need to use some storage mechanism that allows bi-directional lookup of identities starting from your own customer ID or from Slack identities. DynamoDB or Aurora are reasonable choices if you are running in AWS.

There are more considerations beyond these when implementing an inbound Slack integration in your app, including throttling, retries etc.

user_1747860
Related