How a Simple Learning Exercise is Helping Rid Every Slack Channel of Spoilers
“Hey. Did anyone catch the latest episode of Game of Thrones? It was crazy!”
“No. And stop. Don’t type another word! While I am sure every important character was killed, please don’t spoil it for me.”
Slack is quickly becoming the de-facto application used for workplace communication. It’s also becoming the virtual company water cooler, which presents other (unique) problems.
Here at Fount, our team works remotely which makes Slack our primary method of communication. The water cooler chat naturally floats towards which Netflix shows we are binge watching (outside of work hours, of course) and what movies are “can’t miss”. Spoilers are an unfortunate necessity to this type of chatter.
Not familiar with Spoilers? Urban Dictionary explains:
It only took a few spoilers shared within our team Slack channel to force the question: “How could we leverage a Slack bot to alert users that a Spoiler has been entered?”. Coincidentally, we were also looking for a good excuse to build a Slack bot without traditional server costs. We put our heads together to solve both of these problems and out came Spoiler: a free Slack add-in to warn your team of possible spoilers.
How it Works
From any channel within Slack, simply type /spoiler to activate the Slack bot:
Then simply add the text you want to be displayed as a possible spoiler. You can include a subject for the spoiler [within brackets] to indicate what the spoiler refers to:
After hitting enter, the Spoiler Slack Bot takes action and posts the spoiler:
See it in action:
Building Spoiler To Prevent Spoilers
We have built and continue to maintain two other Slack apps: Vote and Export. Both of those apps use a more conventional back-end (a virtual compute instance like Amazon’s EC2). Spoiler was built with a self-imposed restriction on cost and a curiosity to answer the following question:
What if building simple back-ends was not an orchestration headache?
Our goal was to build a slack app while eliminating the need for provisioning an instance, setting up a network and worrying about scaling (OK, thinking about scaling issues at this point is a bit overboard).
Spoiler, after all, just needs to support two endpoints and does not require a persistence layer. Chomping at the bit to play with Amazon’s Lambda functions, this route was chosen as the implementation restriction coupled with the incredibly handy Serverless framework. Lambda functions and ‘serverless’ architecture discussions are out of scope for this post, but essentially, Amazon (and other cloud providers) abstract as much infrastructure away as possible and provide a means to just host a singular function in the cloud that can be invoked in a myriad of ways. In this case, a simple http endpoint invokes the function and a formatted spoiler message is tossed back into Slack.
For simple apps, the serverless architecture is actually a nice pairing. Need a function or two to respond to an event? A simple REST API? Need an asynchronous task worker that can scale on demand? Need a simple Slack bot? Serverless architecture can handle it. However, It is not a one-size-fits-all solution to all problems and even would likely not be a reasonable implementation for our other Slack apps.
In retrospect, proceeding down this route did not likely save us any time vs building a simple Express or Flask app (due to the small learning curve of AWS Lambda and Serverless), but it was a worthwhile learning experience about alternative tools. Serverless themselves even host a few examples of using their framework to build Slack extensions, so the intent of glueing these technologies together is not far-fetched or even interesting at this point.
Considerations
Access Control (Or Lack Thereof)
Spoiler is intended to be a fun app centered around entertainment. To reduce friction, the anonymous spoiler messages utilizes Slack’s slash command APIs. This approach requires *NO* authorization from your users and therefore cannot access their personal information or messages. No access means no risk. The only authorization ever required to use Spoiler is for setting up the /spoiler command when the app is initially installed for your team.
Privacy
We don’t want to see you spoilers either. We made sure there is no personally identifiable information ever persisted for any of your users. Additionally, since Lambda functions are stateless and no database is utilized, it is impossible to persist any data. Even when the command is invoked, no authorization tokens or user identifiable metadata are saved. Nada.
User Feedback
Spoiler has been a great opportunity for us to collect product feedback from users and implement suggestions into the product. Spoiler has been a hit for many Slack teams but there were some improvements that were needed.
The most common suggestion we received was to include a feature that helped identify what the spoiler was in reference to. This would allow users to make a decision on whether or not to see the spoiler based on the topic. As a result, we implemented a feature to optionally include a subject or title regarding the spoiler:
/spoiler Darth Vader is Luke’s father [You’ll never guess who Luke’s dad is]
Join The Resistance
Want to join the global resistance against spoilers? Download the Slack App for your team here and let us know what you think would make it better!
