Serverless and Slack

January 26, 20191 minute

In the early days of building out I was learning about the Serverless framework and the benefits around being able to simply write code without worrying about deployments, security, or infrastructure planning.

The problem

Serverless framework promised me super scalable and encapsulated functions that could be deployed in seconds. So this is what I did; I built my app with this idea that Serverless was the way to go. was originally built as 3–4 functions that dealt with everything: OAuth, slash commands, event subscriptions, you name it.

Slack has a hard requirement of responding to any slash command in under 3 seconds. No matter what I did to optimise the cold-start time or the speed of my code, I simply could not create a consistent Serverless endpoint (via AWS Lambda) that returned a result quick enough. Many of the responses were perfectly fine, but my users were often complaining about timeout issues in their commands. This is not great for user experience.

The "solution"

Kaomoji is now written as an always-on Koa server (deployed by GitLab CI and AWS Elastic Beanstalk) that can consistently respond in less than a second. It's also been a great way to extract some repetitive actions like verifying Slack requests and retrieving user information into isolated and testable middleware functions.

I think Serverless has a place at massive scale, until then for a fast slash command experience , stick with traditional Node.js servers.

This is a preview of a simpler page design that I'm working on over the next little bit. I've finally added a (click it!) but there's still a few pages left to be converted so don't worry if things don't look quite right just yet 🙏

Content on blog pages use the CC-BY-SA license. The source code and notes use the MIT license. Unsure? Mention me on Mastodon.