There are many cool things one can do to leverage the power of Slack – private channels, embedding various content, searching all the messages from one place, sharing files and code, using some of the many available integrations or building one yourself. In this post I will focus on the last one. I have finished such an implementation myself recently. My project was a creation of a simple Slack bot for scheduling foosball games for my teammates called Foosie. It is a Spring Boot application that I open-sourced and it is available on GitHub. In this article I will share some of the noteworthy aspects of this little project and hopefully entice you to give it a try yourself.
Where to start
As with any project, it is important to start with the basics. Clarity on what is the purpose of the product you are developing and the intended use should be a center point which the whole process revolves around. Remember, you are creating an interface for your users, making it easier to access the functionality you implemented.
Notes on design
Depending on the way your bot communicates you should consider what drives the interaction if there is any. In case you are trying to integrate some tool you are using and want to send some statistic or results of some actions, a simple message to a channel of your choice might be just what you need. These applications are usually stateless in their nature which makes the implementation much simpler. You can go even one step further and use the code to customize your statistics. Generate a graph or some nice presentation of the data for purposes of tracking the changes over time.
However, if your application is driven by the user input or requires multiple users collaborating (like mine did) you need to consider tools provided by Slack to facilitate this. In this case, slash commands seem like a way to go. Slash commands are simple to use and they are typically bound to a URL allowing you either to GET or POST messages to the back-end system. Since there might be a plenty of slash commands already in use, you might consider prefixing your set of slash commands to make it easier for your users to find and use them.
Notes on implementation
Given the architecture of Slack and the way it was designed, we the developers gain great degree of freedom when it comes to languages and frameworks to choose from. The whole communication is carried over HTTPS utilizing the REST principles allowing you to communicate with Slack in almost any way (given it supports HTTP calls). When it comes to communication with Slack itself, there are several ways to go and they are nicely described in their official documentation:
Great thing about Slack and its documentation is that they allow you to play around with these ways of integration from documentation page itself so you can see the results in your team or channel. This should give you a good idea about what to do once you start implementing your bot. Webhooks are the simplest of the three allowing your back-end to react to certain actions from your users. Whether it is a link posted by your continuous delivery pipeline, or a query to kick off a build, webhooks are a simple way of facilitating this feature. If more verbosity is what you need, Slash commands might be worth looking into. They allow more advanced communication to take place while not forcing you to go into implementation of more robust solutions. Last of these options is a full-blown messaging API exposing the whole plethora of Slacks APIs and provides all the supported methods one can use to implement their bot (including channel, user, group, team, file and private message related operations).
When it comes to security, there are several mechanisms in place that will help you out trying to secure your bot and the communication with Slack. Communication is carried over HTTPS protocol. You can either make use of OAuth 2.0 which is supported by all the major frameworks at this point, or keep it simple and put a simple token based checks into your code. There are also some limits in terms of number of messages, how often they can be posted as well as timeouts in place guarding the integrity of the content in your channels. The level of the security should match your intended use and the sensitivity of the data being transported over the wire.
Notes on testing
One of the most challenging aspects of bot development turned out to be testing of its feature (at least for the bot I was working on). Good news here is that since we are dealing only with a REST API calls you can leverage mocking to its full potential. I decided to go with mock-server library for my project, since I had good experience with this library from my previous projects. Building at least a semi-robust testing infrastructure proves extremely useful in cases when you have to serve large amount of users or when concurrency needs to be accounted for. I highly recommend not underestimating this step as it is really the only feasible way of assuring the quality and the behavior of your bot.
Notes on documentation
As with any piece of software intended to be used by some else than yourself, the documentation is extremely important. Ideally, the documentation should contain enough information for your users to be able to use your bot. This includes typical use-cases and how to trigger them possibly with a sample responses one might see upon the interaction with your bot. But it shouldn’t end there. If you are using Slash Commands, it makes sense to document also how to set them up, describe them and reveal the intended use. Since someone will need to manage the back-end services as well, you shouldn’t shy away from describing how to stand up these services and their proper configuration. I tried to uphold these rules when I was working on my bot and you can see an example in the readme file of Foosie. I know, shameless plug … right?
Conclusion
Trying to put your first bot together and seeing it work (regardless of the complexity of the operations it performs) is a great exercise. Whether you want to post a random Nicolas Cage expressions into your team channel or roll out a bot bridging your performance monitoring solution and Slack, it is a fun project to work on. I intentionally didn’t include any particular code, or usage of Slacks APIs since you can find enough resources on their official documentation page. If you are curious how such an implementation might look, feel free to check out (or contribute to) my project called Foosie using Spring Boot to host foosball games. Writing your first Slack bot is not a trivial task, however it was easier than I expected it to be. And great fun too.
| Reference: | Building your own Slack bot from our JCG partner Jakub Stas at the Jakub Stas blog. |
