Build Slack Home Tab in minutes using AWS Lambda and Amazon EventBridge
Vacation Tracker, UI for Slack integrations was very limited. You could make your integration interactive by mixing buttons and dropdowns. Luckily, a limited number of interactive elements combined with a grain of imagination lead to countless creative ideas. Not all of them provided the best user experience for our users, but they were way better than our biggest competitor – the big bad spreadsheet.
The first version of our product was similar to the following image. We improvised a calendar using simple buttons. No weekends? The limit was five buttons in a row. It’s a leave-tracking app, who works during the weekends anyway? Many people, as we learned quickly.
Slack improved a lot in the last two years. They added a date picker, modals, input fields, and many other useful UI elements. Besides that, Slack improved its permission scopes, which was very important for Vacation Tracker, because we tried to know just a few most basic things about our users.
Our product was better than ever as one of our latest feedbacks says it’s super easy to use, much better than submitting paper forms. Managing your leave days is just one Slack command away.
However, not all of our users know how to use slash commands. Was it slash (“/”) vacation, hashtag vacation, or some other weird character?
Wouldn’t it be nice if we could have a place in Slack where users can find everything they need to know about Vacation Tracker? Something like a simple dashboard. Fortunately, someone at Slack thought the same.
introduced the Slack app toolkit
An App Home is dynamic. We can use an App Home and Block Kit to show all critical information from Vacation Tracker to our users just in time. Even if our users do not know how to use slash commands, they’ll be able to request leaves directly from Slack by clicking the button in the Home tab.
It sounds like a significant improvement for our UX! Where do we start?
You also need to create a Slack application and install it in your workspace, which is beyond the scope of this article, but many other guides cover it.
views.publish
Web API method. You can see more details about this API method and supported blocks by visiting an official Slack guide
views.publish
app_home_opened
event. You can set up a webhook to receive the app_home_opened
here and here on our blog, or in a few external sources, such as the AWS blog, and other websites
AWS Lambda Provisioned Concurrency
Our initial architecture was similar to the following diagram. We connected all Slack webhooks to our API Gateway. The API Gateway then triggers different Lambda functions for different types of Slack integration (events, slash commands, or dialogs). Each of these functions parses the Slack messages, publish them to our Amazon Simple Notification Service (SNS) topic, and responds to Slack with a 200 OK status. Then the SNS topic triggers other Lambda functions that do the business logic.
create another AWS Serverless Application Repository (SAR) application
To learn more about SAR, read our previous article about the generic webhook handler here. To learn more about building and publishing serverless apps on SAR, see this excellent article.
As you can see in the following diagram, the architecture of our new integration looks similar to our initial architecture. However, there are two crucial differences: our SAR application hides webhook and event processing, and we replaced Amazon SNS with Amazon EventBridge. The EventBridge is a new service that brings a fully managed enterprise service bus to an AWS serverless offering. You can publish all the events there and then subscribe to your Lambda functions to one or multiple events containing a specific parameter. For example, you can trigger a specific function when the user opens a Slack Home Tab!
Let’s dive into the most exciting part of this article – the code.
The easiest way to demonstrate the way our new SAR app works is to build something. So let’s build a simple to-do list that looks similar to the following mockup.
AWS Serverless Application Model (SAM). These prerequisites are beyond the scope of this article, but many online resources can teach you the basics of serverless and SAM. If you prefer books, you can check the excellent Running Serverless
node12.x
runtime. And open your template.yaml
If you are using the new sam deploy --guided
command, deploy the application once before modifying your template.yaml
file. Then open the samconfig.toml
file, and replace the following line:
capabilities = "CAPABILITY_IAM"
With the following configuration:
capabilities = "CAPABILITY_IAM CAPABILITY_AUTO_EXPAND"
This “CAPABILITY_AUTO_EXPAND” capability allows you to install SAR applications using SAM.
template.yaml
The previous code sample will setup the basics of your serverless application. This template does the following:
- It passes the two parameters to your SAM app:
EventBusName
– tells SAM how to name your event bus, “SampleSlackEventBus” is a decent name.BotToken
– tells your app which bot token to use. In production, you probably want to get this from the API, but for a sample app you can pass a value from the “Install App” tab of your Slack App settings
- It sets the function’s global configuration, so you don’t need to repeat that in each of your functions.
- It defines resources, which we’ll do in a few minutes.
parameter_overrides = "EventBusName=EVENT_BUS_NAME BotToken=xoxb-YOUR-BOT-TOKEN"
template.yaml
Now you have everything you need to start handling the events. The first event we want to handle is the opening of the App Home tab. Add the following Lambda function to the resources section of your template.yaml file.
SlackHomeTab
represents the name of your Lambda function. You can change this, but try to make it descriptive.Type: AWS::Serverless::Function
tells SAM that you want to add a Lambda function.Properties
define a list of properties for your function.CodeUri: build/home-tab
tells SAM to take the app code from the “home-tab” folder, located in the “build” folder. We use TypeScript for our Lambda functions if your source code is in some other location change this line.Handler: lambda.handler
tells SAM that we exportedhandler
function from the lambda.js file. Change this value if your function or the file are named differrently.- The
Environment
section defines environment variables. We do not want to hardcode our bot token, so we pass it as theBOT_TOKEN
environment variable in this section. - The
Events
section defines an event that triggers your Lambda function.
And now we came to the most exciting part of the code. See the following code example:
This pattern tells an EventBridge event bus to trigger this specific function if the event contains the following structure:
Our SAR application, in combination with the EventBridge, makes a powerful but easy-to-use library for Slack integrations. Besides specific events, you can target a specific slash command or even click on a specific button in your Slack app.
template.yaml
As you can see, the only difference is the event pattern. Slack buttons send a payload that contains actions. If one of the actions has the “add_todo” value, EventBridge invokes this function.
template.yaml
npm install
command to install the dependencies. Then run the npm run build
command to build the TypeScript code. And finally, run the sam deploy
The deployment should output the webhook URL. Set this URL as a webhook URL in the “Event Subscriptions” and the “Interactive Components” sections in your Slack application settings.
The result should look similar to the following gif:
Not bad for a few minutes of coding!
This architecture gives you a simple but flexible and scalable architecture for your Slack integrations. By default, your integration can handle up to 1000 parallel requests. You can increase this number via AWS support. It gets even better; you are charged per usage. If no one uses your Slack integration, the infrastructure is free.
As a next step, you should add a database that would store bot tokens and other user preferences. We recommend using DynamoDB, AWS database that scales automatically and is an excellent fit for a serverless application.
You can also subscribe to our newsletter if you want to get articles similar to this one directly in your inbox.
Now, go and build something amazing! Keep an eye on the Vacation Tracker Home tab, which we’ll roll out to our users in the following few days.
CTO and co-founder of Vacation Tracker, AWS Serverless Hero, and co-author of Serverless Applications with Node.js, published by Manning Publications.