Building Slack /slash commands with AWS Lambda

Mar 28, 2016 3 min readWorkplace of the future

When AWS Lambda came out last year I was amazed.  The thought never occurred to me that web development doesn’t need to be complex, instead it can be about purely accomplishing the task at hand.  While they’re relatively early still, I think AWS Lambda and AWS API Gateway, are great examples of where web development is headed.

If you haven’t experimented with AWS Lambda yet, I’d definitely recommend doing so.  Essentially it’s a model of web development in which you no longer need to worry about the underlying architecture and how it scales.  The idea is you create and deploy mini, single purpose functions at a time, and AWS does the hard work of server provisioning, scaling and monitoring.  With Lambda, you pay for the actual running time execution of your code and how much memory you use.  If your function is never called, you don’t pay for it.  At Buffer we’ve started to use AWS Lambda for certain what I call, ‘nano-tasks’ that are typically caused by a user event like handling image resizing, generating PDFs, posting multiple images or videos to Twitter etc.

Using Slack to trigger application deploys

At Buffer, we love Slack.  Slack has helped our remote team communicate and connect and of course the integrations are lifesavers.  This weekend I was looking into building some Slack slash commands to help the Buffer team be further productive.

One thing we’ve been proud of is how easy it is to deploy the Buffer application to production.  We’ve set up @Bufferbot as a bot to help us to trigger a deploy.

For instance, to kick off a deploy, within Slack, Buffer engineers will do:

This deploy process has worked well for us for over two years and I was hoping to bring this same flow for the Respond team.  The Respond team has been deploying by manually going to a Jenkins server and kicking off a deploy from there–definitely not as smooth as deploying to Buffer.

Bufferbot and is built on top of Github’s hubot.  It’s an app hosted on Heroku and is always running.   You can imagine that while it’s always running we only really call it at most 20 times a day during the week, which is not necessarily the best use of resources.

Discovering Slack + AWS Lambda

I could have easily set up the new Respond slack deploy using the same Heroku/Hubot approach, but then I came across this article from the AWS team.  It immediately hit me that I could save money, time and ops overhead by using AWS Lambda to power my slash commands rather than using Heroku (or any other server set up).

In fact, the AWS Lambda team has done a great job setting up boilerplate templates for anyone to create their Slack slash commands.   I ended up building the /deploy-respond command in less than an hour thanks to the AWS folks (and I don’t have to worry about the ops side too!).

Deploys to Respond are as simple as:

/deploy-respond app master

Implementation

For those interested in the steps, these were the steps I took:

  1. Navigate to the AWS Lambda console page and create a new Lambda Function.  Choose ‘slack-echo-command’ blueprint
  1. Follow the steps to create it.  It’ll also provision an AWS API Gateway Endpoint
  2. Once you finish the steps, you’ll be taken to where you can alter the source for the Lambda function.  It’s there that you’ll see the template for creating a Slack echo bot.  You can follow the comments to test out your slash commands.  I’ve included the blueprint code below if you’re curious.

Have you built some cool Slack /slash commands or slack bots? We would love to hear about the Slack integrations your team uses!  We’re hoping to build much more into our Slack experience this year!

Brought to you by

Try Buffer for free

140,000+ small businesses like yours use Buffer to build their brand on social media every month

Get started now

Related Articles

OpenNov 9, 2023
Buffer is Remote but not Async-First, Here's Why

With so many years of being remote, we’ve experimented with communication a lot. One conversation that often comes up for remote companies is asynchronous (async) communication. Async just means that a discussion happens when it is convenient for participants. For example, if I record a Loom video for a teammate in another time zone, they can watch it when they’re online — this is async communication at its best. Some remote companies are async first. A few are even fully async with no live ca

Z - PopularSep 29, 2023
How to Send Better Email: 7 Ways To Level Up Your Email Skills Today

Like many others, I read and reply to hundreds of emails every week and I have for years. And as with anything — some emails are so much better than others. Some emails truly stand out because the person took time to research, or they shared their request quickly. There are a lot of things that can take an email from good to great, and in this post, we’re going to get into them. What’s in this post: * The best tools for email * What to say instead of “Let me know if you have any questions” a

22 Side Projects From the Buffer Team

At Buffer, we’ve long had teammates who have side projects in addition to working at Buffer. It’s pretty common for our team to run their own blog, we have several published authors on the team, and many of our engineers run apps that have nothing to do with their regular work. Though some companies prefer that anyone on their team not have side projects and actively discourage it, that has never been our way at Buffer. In fact, working at Buffer means you get a free Buffer account, making it e

140,000+ people like you use Buffer to build their brand on social media every month